Reputation: 52331
Currently, I work on an ASP.NET project which is hosted under version control and is used on several developer machines, tester machine and production environment.
In three cases, configuration (Web.config) may be different. For example, developer and tester environments use testing SQL Server, whereas in production environment, another SQL Server is accessed, so the connection string is different in those cases.
We want to keep three versions of Web.config in subversion. But modifying each of three files every time we need to add, remove or change a common setting is annoying: it would be nice to have a common, master Web.config, which will be inherited by each of the three Web.config files.
How to set up an ASP.NET project which will use a master configuration file and different slave configuration files on different machines, thus sharing the same project/source code/configuration files in subversion?
If .NET Framework is unable to do that, what are the alternatives (to avoid reinventing the wheel and/or to see how it works if there is a need to build a custom solution)?
Upvotes: 2
Views: 2211
Reputation: 15663
If I were starting today, the web.config transforms feature of VS 2010 is definitely worth a look. But I had to solve this problem before tool support was avaliable, and I also think that transforms are nice, but sometimes they just don't cut the mustard -- especially if you have lots of heavily configuration driven stuff or production configurations that can change without the dev team knowing about it.
How we tackle this is to keep separate copies of the configurations. The one stored within the project root is for our standardized development environment. It is also set as a "content" file which is not copied to the output folder. The environmental ones are stored outside the project from a visual studio standpoint but still in the same version control, in a folder for every environment and facet (we have lots of multi-headed web apps with separate admin tools). We tie it all together using a build script that copies the right configurations depending on the declared environment.
We have found this works quite a bit better than the transforms in practice -- main thing being the production configurations are so different that there is perhaps more transform than configuration. Also allows us to keep the production configuration in synch as it is really just a file copy, not an update of some horrid XSLT.
Upvotes: 2
Reputation: 161791
Visual Studio 2010 has this feature, called "web.config transforms". You have a base web.config, then, for each configuration, you have transform files, that effectively "edit" the base web.config for the particular environment.
Example from the default Web.Debug.config file:
<?xml version="1.0"?>
<!-- For more information on using web.config transformation
visit http://go.microsoft.com/fwlink/?LinkId=125889 -->
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<!--
In the example below, the "SetAttributes" transform will change the value of
"connectionString" to use "ReleaseSQLServer" only when the "Match" locator
finds an atrribute "name" that has a value of "MyDB".
<connectionStrings>
<add name="MyDB"
connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True"
xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
</connectionStrings>
-->
<system.web>
<!--
In the example below, the "Replace" transform will replace the entire
<customErrors> section of your web.config file.
Note that because there is only one customErrors section under the
<system.web> node, there is no need to use the "xdt:Locator" attribute.
<customErrors defaultRedirect="GenericError.htm"
mode="RemoteOnly" xdt:Transform="Replace">
<error statusCode="500" redirect="InternalError.htm"/>
</customErrors>
-->
</system.web>
</configuration>
Upvotes: 2