Using the T4 template to generate configuration files in different deployment environments

When developing enterprise applications, there are often different development environments, such as development environments, test environments, formal environments, production environments, and so on. When a code is deployed to different environments, the configuration files for different environments may need to be different depending on the target environment. For example, in a development environment where a database uses a database of development environments, Message Queuing also uses Message Queuing deployed on a development machine, traditionally by publishing or configuring administrators to maintain configuration files for these different environments. In general, it is easy to create errors by manually modifying configuration files for different environments.

There are many different ways to build configurations for different deployment environments, and the stupidest way to do this is to maintain several sets of different configuration files, and then copy the corresponding configuration files according to the compilation environment variables in the compilation event, or you can use the PostBuild event script in MSBuild to modify the original configuration file. Replace the variables or parameters that are related to the target environment, and some tools, such as Configgen, that can replace the original configuration file based on the additional environment-related configuration files. Here's how to use the T4 template to generate a different configuration file.

Example

The T4 template is a popular code generation engine. The entityframework in. NET also seems to use the engine to generate ORM code. In Visual Studio, you can identify and support T4 template files. Visual Studio has some addin, such as T4 Editor, which facilitates the writing of T4 template files. To demonstrate how to generate a configuration file based on using the T4 template, first create a simple console application:

1. Open Visual Studio and 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=.;i Nitial catalog=northwind;integrated security=true "            providername=" System.Data.SqlClient "/>    </ Connectionstrings></configuration>

3. Then add a new text file named App.tt, copy the contents of App. Config, and make some changes, as follows:

<#@ template= "" Language= "C #" #><#@ output= "" extension= ". config" #><?xml version= "1.0" encoding= "Utf-8 "?><configuration>    <connectionStrings>        <add name=" Northwind "            connectionstring=" Data Source=.;i Nitial catalog=northwind;integrated security=true "            providername=" System.Data.SqlClient "/>    </ Connectionstrings></configuration>

Save, you can see that app. config is already under App.tt, and Visual Studio is able to recognize the. tt file and use the App.tt file to generate the app. config file. The app. config file itself has not changed, but now exists with APP.TT. Notice that the database here is the local database.

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

<#@ 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=.;i Nitial catalog=northwind;integrated security=true ";  #>

In this version of App.tt, NorthwindConnectionString is now a private field in a template. We initialize it for him, and as a value for the parameters in the template.

5. Now add a new template file named Dev.tt, which reads as follows:

<# 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. This string configuration overrides the string configuration in App.tt, where you can see that the database is connected to a server named Dev-server. When you save Dev.tt, Visual Studio automatically generates the Dev.config file and then adds it to the Dev.tt file. The contents of the Deve.config file are 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 is similar to the content of App. Config, except that the database server becomes Dev-server.

6. In Visual Studio, set the copy to Output directory property 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 to copy the Dev.config to the development environment instead of the default app. config. The deployment script also needs to re-name the Dev.config as a configuration file that the target application recognizes, depending on the application. For example, the ConsoleApplication1.exe.config in this example

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

Improved

Sometimes, putting all the configuration items in one file makes the whole file look messy, so you can make some improvements to the configuration file. For example, you can move the configuration connectionstrings for the database connection string into a separate file, and move the AppSetting subkey to a separate file.

General configuration file, Web. config is as follows, this inside appsettings inside the RABBITMQ message queue configuration, Connectstrings contains the database connection string:

<?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 approach would be to put appSettings and connectionStrings in their respective configuration files, and the 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 and is designed to hold the child configuration. Appsetting.config content is 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>

Connectionstring.config content 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 this modification, the main web. config file looks relatively concise, which can put some configuration unrelated to the deployment platform, such as registering some httphandler. Other configuration subkeys related to the deployment platform, such as appsetting,connectionstring in the previous example, can be made into T4 template files that generate corresponding configuration items based on different deployment environments. Finally, it is important to note that at compile time in the compilation event, the subkey and the folder in which it resides are copied to the post directory. This allows the system to find the configuration file for the subkey based on the path relative to the master configuration file. Summarize

This paper introduces a method of using T4 template file to generate the corresponding configuration file automatically in different environment, and introduces the improvement of configuration file, that is, the handle configuration item is moved to stand-alone configuration file, and then the method of modifying the subkey configuration file to template file is compiled and deployed. It is necessary to write the corresponding script and use the environment variables of the compilation tool to copy the configuration file of the corresponding environment into the compiled directory. This approach teaches the traditional code to be published in a different environment, and manual maintenance and modification of the configuration in each environment can reduce the occurrence and workload of errors. I hope that the content described in this article for everyone in different environments to generate configuration files for reference and help.

Using the T4 template to generate configuration files in different deployment environments