Use the T4 template to generate configuration files in different deployment Environments

When developing enterprise-level applications, there are usually different development environments, such as development environments, test environments, formal environments, and production environments. When a piece of code is deployed to different environments, the configuration files in different environments may vary depending on the target environment. For example, in the development environment, the database uses the development environment database, and the message queue is also deployed on the development machine. The traditional method is, the release or configuration Administrator is responsible for maintaining configuration files in different environments. Generally, manual configuration file modification for different environments is prone to errors.

There are many different ways to generate configurations for different deployment environments. The most stupid way is to maintain several sets of different configuration files, then, copy the corresponding configuration file based on the compiling environment variables in the compilation event. You can also use the postbuild event script in msbuild to modify the original configuration file, replace the variables or parameters related to the target environment. Some other tools, such as configgen, can replace the original configuration file according to the additional environment-related configuration files. Here we will show how to use the T4 template to generate different configuration files.

Example

T4 template is a popular code generation engine .. The entityframework in. Net also seems to use this engine to generate the ORM code. Visual Studio recognizes and supports T4 template files. Visual Studio has some addin. For example, T4 editor can easily assist in compiling T4 template files. To demonstrate how to generate a configuration file based on the T4 template, first create a simple console application:

1. Open Visual Studio to create a console application

2. In the default app. config configuration file, add a database connection string, for example:

<?xml version="1.0" encoding="utf-8" ?><configuration>    <connectionStrings>        <add name="Northwind"            connectionString="Data Source=.;Initial Catalog=Northwind;Integrated Security=True"            providerName="System.Data.SqlClient" />    </connectionStrings></configuration>

3. Add a new text file named app. tt, copy the content in APP. config, and then make some modifications as follows:

<#@ template="" language="C#" #><#@ output="" extension= ".config" #><?xml version="1.0" encoding="utf-8" ?><configuration>    <connectionStrings>        <add name="Northwind"            connectionString="Data Source=.;Initial Catalog=Northwind;Integrated Security=True"            providerName="System.Data.SqlClient" />    </connectionStrings></configuration>

Save, you can see that app. config is already under app. tt. Visual Studio can identify the. tt file and use the app. tt file to generate the app. config file. The app. config file does not change, but is now in the app. tt file. Note that the database here is a local database.

4. Modify app. tt so that the database connection string exists as a parameter, as shown below:

<#@ template language="C#" #><#@ output extension= ".config" #><?xml version="1.0" encoding="utf-8" ?><configuration>    <connectionStrings>        <add name="Northwind"            connectionString="<#= this.NorthwindConnectionString #>"            providerName="System.Data.SqlClient" />        </connectionStrings></configuration><#+     string NorthwindConnectionString = "Data Source=.;Initial Catalog=Northwind;Integrated Security=True";  #>

In app. tt of this version, northwindconnectionstring is now a private field in the template. We initialize it and use it as the parameter value in the template.

5. Now, add a new template file named Dev. TT with the following content:

<#    this.NorthwindConnectionString = "Data Source=DEV-SERVER;Initial Catalog=Northwind;Integrated Security=True";   #><#@ include file="App.tt" #>

This template file contains the app. tt template file. The string configuration in this will overwrite the string configuration in APP. tt. here we can see that the database is connected to the server named DEV-SERVER. When Dev. Tt is saved, Visual Studio automatically generates the dev. config file and adds it to the dev. tt file. The content of the deve. config file is as follows:

<?xml version="1.0" encoding="utf-8" ?><configuration>    <connectionStrings>        <add name="Northwind"            connectionString="Data Source=DEV-SERVER;Initial Catalog=Northwind;Integrated Security=True"            providerName="System.Data.SqlClient" />    </connectionStrings></configuration>

As you can see, this configuration file and App. config content is very similar, but the database server becomes a DEV-SERVER.

6. In Visual Studio, set the copy to output directory attribute of the dev. config file to copy If newer, so that Visual Studio copies the file to the compiled directory.

7. Modify the deployment script and copy Dev. config to the development environment, instead of the default app. config. The deployment script also needs to rename Dev. config as a configuration file that can be identified by the target application based on different applications. For example, leleapplication1.exe. config in this example

8. Repeat steps 5-7 to create a config file for different deployment environments.

Improvement

Sometimes, placing all configuration items in a file will make the entire file look messy, so you can make some improvements to the configuration file. For example, you can move the connectionstrings configuration for the database connection string to a separate file and move the appsetting subitem to a separate file.

The general configuration file web. config is as follows. The configuration of the rabbitmq message queue is stored in the deletequeue, and the database connection string is stored in connectstrings:

<?xml version="1.0" encoding="utf-8" ?><configuration>  <appSettings>    <add key="RabbitMQHost" value="192.168.1.1"/>    <add key="RabbitMQUserName" value="admin"/>    <add key="RabbitMQUserPwd" value="11111" />  </appSettings>    <connectionStrings>    <add name="Northwind"        connectionString="Data Source=DEV-SERVER;Initial Catalog=Northwind;Integrated Security=True"        providerName="System.Data.SqlClient" />  </connectionStrings></configuration>

A better way is to put the appsettings and connectionstrings in their respective configuration files. Web. config is as follows:

<?xml version="1.0" encoding="utf-8" ?><configuration >    <appSettings file="Config\AppSetting.config">  </appSettings>  <connectionStrings configSource="Config\ConnectionString.config">  </connectionStrings>  </configuration>

A folder named config is created under the project to store the Sub-item configuration. The contents of appsetting. config are as follows:

<?xml version="1.0" encoding="utf-8" ?><appSettings>  <add key="RabbitMQHost" value="192.168.1.1"/>  <add key="RabbitMQUserName" value="admin"/>  <add key="RabbitMQUserPwd" value="11111" /></appSettings>

The content of connectionstring. config is as follows:

<?xml version="1.0" encoding="utf-8" ?><connectionStrings>  <add name="Northwind"      connectionString="Data Source=DEV-SERVER;Initial Catalog=Northwind;Integrated Security=True"      providerName="System.Data.SqlClient" /></connectionStrings>

After such modification, the configuration file of the main web. config looks concise. You can put some configuration irrelevant to the deployment platform, such as some registered httphandler. Some other configuration items related to the deployment platform, such as appsetting and connectionstring in the preceding example, can be made into a T4 template file, which generates corresponding configuration items based on different deployment environments. Note that during compilation, You need to copy the sub-item and its folder to the released directory. In this way, the system can find the configuration file of the sub-item based on the path of the master configuration file. Summary

This document describes how to use a T4 template file to automatically generate the corresponding configuration file in different environments and how to improve the configuration file, that is, move the sub-configuration item to an independent configuration file, and then modify the sub-configuration file to a template file. When compiling and deploying these methods, you must write the corresponding scripts, use the environment variables of the compilation tool to copy the configuration files of the corresponding environment to the compiled directory. In this way, after the traditional same code is published to different environments, manual maintenance and modification of the configuration in each environment can reduce the error occurrence and workload. I hope this article will help you to generate configuration files in different environments.

Use the T4 template to generate configuration files in different deployment Environments