Web. config configuration in multiple Environments

Because our development involves the local, test, and production environments, the manager recently asked to write a web. config, you can use a program to determine the current running environment, and then use a custom node to retrieve various variables in the corresponding environment, instead of maintaining them separately like preparing three different configuration files in the past.

Although I have a general idea, I still feel a little confused about the specific implementation. I found a bunch of materials and still felt dizzy)

 

This article aims to separate the variables in each runtime environment, and then jump to the corresponding config in the total web. config.

But my question is, how can I extract the variable values from various configuration files in the past? @_@

Now you can get the name of the current environment through code, but you can easily determine which sub-config to call in Web. config. But what then ??? How can I write code to access the variable in the sub-config ????

No clue... 555555555

I should write it in the same file ~ The call method written together has not been fully understood... t_t

Crying, not at all...

========================================================== ========================================================== =

Web. config Configuration Management Solution in multiple Environments

 

Problems

In large-scale Web application development, in order to ensure the quality of applications and user experience, we always go through the process from development, testing, Beta to final launch.

Because the parameters of different test run environments are different, we can write multiple web. config in actual development. Each web. config is used in a specific test run environment. All of these seem to work properly, but as your application grows, Web. config will become larger and larger, and the troubles will follow.

 

 

Complex web. config is difficult to maintain, and it takes a whole body to start. For example, if you have a configuration section to modify during development, the section corresponding to Web. config in all environments will also be modified accordingly. Especially when the web. config is very large and there are many testing environments, the SCM administrator will be crazy ......

 

To zero

Fortunately, Microsoft has provided the configsource attribute since. NET 2.0 so that we can split web. config. Let's look at a simple example:

 

 
...

<system.web>

...

<profile configSource="profile.config" />

...

</system.web>

...

 

 

 

 

<profile>

<properties>

<add />

<add />

</properties>

</profile>

 

 

 

In the preceding example. the Web/profile> Configuration section is split. The specific configuration in this section is stored in another separate file profile. config, while web. config Only needs to use the configsource attribute to specify the file in which the configuration section is stored. config will automatically find the file and load it at runtime.

Note the following points when Splitting:

• Only the configurationsection can be split, but not the configurationsectiongroup or element.

• The suffix of the file that stores the configuration section content must be careful. Theoretically, the file name can be retrieved at will, and Web. config can be read. For security reasons, we recommend that you do not directly access the file type through the URL to prevent configuration information leakage. We do not recommend that you use extensions such as .config, .xml, and. txt.

• By default, if the content of the config file in a specific configuration section is changed, IIS cannot detect it, so the program pool will not be restarted. If you need to modify the config file in the specific configuration section to enable IIS to automatically detect and restart, you can use the restartonexternalchanges attribute. For details, see msdn.

 

Divide and conquer

The trick is to split web. config by using the configsource attribute. How can we split our web. config to achieve the most effective configuration management? Because our splitting is based on the configuration section, which configuration sections do we need to split?

We can find that the configuration section of the following features can be included in our consideration:

• Frequent changes

We often need to modify or update some configuration sections during development. If you can pull the configuration separately, you do not need to touch web. config during modification.

The same configuration section config is referenced in Web. config in different environments. Therefore, you only need to modify the configuration once instead of modifying the Web. config in all environments.

• A large number of lines of content

Sometimes some configuration sections in Web. config are large, which affects the overall aesthetics of Web. config. We can extract the contents of these configuration sections separately, so that web. config is much simpler and easier to read.

• Configuration section content is different in different environments

We often have such configuration sections, and the content in different environments is different (nonsense... Are there so many different web. config jobs... --). In this case, we can fully consider splitting and generating configuration files in different environments. For Web. config in different environments, you only need to reference the configuration section file of the corresponding environment. Even if the environment changes, you do not need to change web. config. You only need to modify the configuration section file in the corresponding environment.

 

Of course, these three features are not mutually exclusive. It is very likely that a configuration section contains the above two or three features. These configuration sections need to be taken seriously and split by multiple policies.

 

Regions

If the web. config is very complicated, and the split result may be a bunch more ***. so we need a simple and effective naming convention to manage so many configuration files.

 

• Web. config: files in different environments can be named Web. Local. config, Web. Beta. config, and Web. Release. config.

 

• Feature 1, 2 configuration section File: You can name the configuration section, such as profile. config. The specification should be web. profiling. config, similar to web. httphanders. config, Web. httpmodules. config and so on.

 

• Feature 3 configuration section File: if there is a dbconfig configuration section (database connection configuration in different environments), we can name it web. dbconfig. local. config, Web. dbconfig. beta. config, Web. dbconfig. release. config.

 

With the divide-and-conquer management and standardized naming, we can easily manage configurations, you don't have to face the seemingly identical and somewhat different things all day long. You must be clear about what's different, but it's hard to find out what's different. In the end, you don't even know whether it's the same web. config.

 

Some large systems may have different configurations on each Web server. For distributed reasons, the databases connected to each web server may not be different. In such a more complex situation, you can certainly implement it by developing more complex naming rules. However, in many cases, online conditions change at all times. For example, if a database is ready, the Web must be switched to another database for access. Therefore, this solution is not very suitable for large-scale distributed Web applications. You can consider implementing feasible solutions through configuration management middleware. I will share my research with you in the future.

 

Original post address: http://it.dianping.com/using-configsource-to-split-web-confi.htm