I want to know what best practice is for accessing settings
in config file when you have dev/test/production types.
If you have different config for each type when you
publish a ASP.NET website doesn't the config get copied as well??
Malcolm
We usually manually inject the settings file on each site. I think that it's uncommon, though not unheard of, to actually rely on VS to publish to your production site. Source control has dev/test/prod/ etc. web.config files.
ConfigurationManager.AppSettings ?
http://msdn.microsoft.com/en-us/library/system.configuration.configurationmanager.appsettings.aspx
In Visual Studio 2010 you can maintain Multiple Web.Config and use a transformation to generate the correct Configuration for an environment.
http://blogs.msdn.com/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx
Basically we can make have one default Web.Config and different Transformation files for each environment e.g.
Web.Debug.Config
Web.Staging.Config
Web.Production.Config
The Transformation file can override the value of a particular config item for the environment e.g.
<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<connectionStrings>
<add name="personalDB"
connectionString="Server=StagingBox; Database=personal; User Id=admin; password=StagingPersonalPassword"
providerName="System.Data.SqlClient" xdt:Transform="Replace" xdt:Locator="Match(name)" />
<add name="professionalDB"
connectionString="Server=StagingBox; Database=professional; User Id=professional; password=StagingProfessionalPassword"
providerName="System.Data.SqlClient" xdt:Transform="Replace" xdt:Locator="Match(name)"/>
</connectionStrings>
</configuration>
Whenever we target build for that environment the Transformation are applied to the default Web.Config file.
Related
I'd like to transform the appsettings section of my local web.config file from a bunch of individual settings for my local dev work, to a configSource file path attribute for publishing to client servers.
Basically from this:
<appSettings>
<add key="setting1" value="devVal1"></add>
<add key="setting2" value="devVal2"></add>
<add key="setting3" value="devVal3"></add>
</appSettings>
to this:
<appSettings configSource="clientSettings.config" />
This partial solution adds the configSource attribute.
<appSettings xdt:Transform="SetAttributes(configSource)" configSource="clientSettings.config"/>
But I'm not sure how to remove all the individual settings as well (I think the configSource will override them anyway, but I'd prefer to not have them there at all, to avoid having irrelevant dev settings in each of my client's web.config files)
A bit more perseverance lead me to the answer. Apply the "RemoveAll" transform to an add element within the appSetting.
<appSettings xdt:Transform="SetAttributes(configSource)" configSource="clientSettings.config">
<add xdt:Transform="RemoveAll"/>
</appSetting>
Hope this is of use to someone in the future (if only as an example of why you should do 30 minutes of extra work before reaching for the 'Ask Question' button)...
I have a web application in VS2010 with a web.config like this:
...
<configuration>
<connectionStrings>
<add name="ApplicationServices"
connectionString="data source=MyProdDb;Initial Catalog=MyCat;User Id=MyUser;Password=MyPass;"
providerName="System.Data.SqlClient" />
</connectionStrings>
...
and a Web.Debug.config like this:
...
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<connectionStrings>
<add name="ApplicationServices"
connectionString="data source=MyDevDb;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true"
xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
</connectionStrings>
...
The project is set to create a Debug build, and when I run it in the debugger, I get MyProdDb rather than MyDevDb
What am I missing?
UPDATED INFORMATION
Arbitrary XML-based .config files can now be processed, and the processing can happen at build time rather than at deployment time
http://www.hanselman.com/blog/SlowCheetahWebconfigTransformationSyntaxNowGeneralizedForAnyXMLConfigurationFile.aspx
Brilliantly, the transforms can also be previewed directly in Visual Studio.
As people have said the web.config versions only get applied at publish (MSDeploy) time. The normal way you would do things is to have your 'Debug' config in the actual web.config file and make changes to that for each of the deployment scenarios you have.
What am I missing?
You are missing the fact that web.config transformation occurs only when you do a deployment. If you don't publish your web application you cannot expect any transformation to occur. If you just run your website locally by hitting F5 no transformation will occur. It's only when you publish the application that the transformation is performed.
Web.config transformations gets processed at publish time only. When debugging (even in release mode), the basic Web.config file is being used.
I am using MVC3, and I am wondering what is the best way to distinguish your environment? For instance I am thinking of adding a key to appSettings and referencing it, however in MVC3 is there a better way? I am working on 3 environments: Development, Staging, and Production.
Thanks
I use the configuration manager and define DEBUG, TEST, RELEASE as compile time constants. For configurations I use Web.config Transformation Syntax for Web Application Project Deployment and would highly recommend using them.
For example:
//web.config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<connectionStrings>
<add name="MyConnectionString"
connectionString="Data Source=SqlServer\Sql2008;
Initial Catalog=MyDB.Dev;
Integrated Security=SSPI"
providerName="System.Data.SqlClient" />
</connectionStrings>
<add key="SomeAppSetting"
value="DebugValue"/>
</configuration>
Test transformation:
//web.Test.config
<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<connectionStrings>
<add name="MyConnectionString"
connectionString="Data Source=SqlServer\Sql2008;
Initial Catalog=MyDB.Test;
Integrated Security=SSPI"
providerName="System.Data.SqlClient"
xdt:Transform="SetAttributes"
xdt:Locator="Match(name)"/>
</connectionStrings>
<add key="SomeAppSetting"
value="TestValue"
xdt:Transform="SetAttributes"
xdt:Locator="Match(key)"/>
</configuration>
When I change my configuration from debug to test and rebuild/deploy my app now uses the transformation update in my web.Test.config. Extremely useful.
You can build different configurations using the Configuration Manager Dialog Box. At anytime you can right click on the web.config and select Add Config Transformations to have Visual Studio 2010 create the transformation config files automagically.
Web.config is probably a good place, for the MVC UI project. assuming that data layer and service layer are separated you would also have entries in those other projects.
I would recommend taking a look at web config transformation. Once you have the basis of your web.config setup you would create a transformation for your staging and production environments.
Many good examples on the net if you require more info.
We are working on a web application that creates more web applications.
Each web application will have to get a Url Rewrite rule (URL REWRITE MODULE 2.0).
As far as I know, there's no way to add such rules without modifying the web.config file (am I right??).
So my plan was to work with multiple web.config partial files. One main .config file, and lots of .config files per application (every file will contain it's web application url rewrite rules).
This way sounds a little bit messy, but I can't think of anything else, and suggestions will be welcomed.
So is it possible to use very-multiple web.config files for the root application?
Thanks in advance, Gal.
This following Tag will do the trick.
The absence of this tag was the main reason for my problem when i using with two web.config files for my two different application running in my website.
**<location path="." inheritInChildApplications="false">**
<system.web>
<!-- ... -->
</system.web>
**</location>**
Every application must have a full web.config and not partial, exept if you go with net 4
The trick is to use a lot the remove command on the other inside web.config and remove the parents setting that must not used on this.
For example if on the main root you have the a module that you do not won to use it on the other trees, you use the remove command on all other web.config to remove it. Especial the modules that are on one Bin and not on an other directory bin.
<httpModules>
<remove name="TheHttoModuleNotNeedHere" />
<remove name="AnonymousIdentification" />
... add here your other modules for that directory...
</httpModules>
The remove command is working for almost all sessions on config.
You can do make it work, I have done it, but its a lot of work to find all the conflicts/unnecessary configs and remove it.
For some other session there also the clear command. For example on role Manager you can clear all and add new.
<roleManager enabled="true" ...>
<providers>
<clear />
<add name="MyName" ... type="System.Web.Security.SqlRoleProvider" />
</providers>
Hope this help as tips to make it work.
I want to create a generic web.config file for different web servers in VB.NET. So, depending on the server configuration requirements, applications can retrieve all values from that generic configuration file.
Is this possible? How would I do this?
This is just a random idea, it may not fit your needs though. You could create a configuration section for each server named by the name of the server. Create a helper class for reading configuration values that checks for any values in the section named after the server's name first, if it doesn't exist read it from a default configuration section.
I'm still not sure if this would be a wise decision, its just an option.
Technically, there's the machine.config which includes settings that apply to the entire machine.
web.config files can override some settings from it.
For everything that stays the same, use the a single web.config.
For everything that changes, use a reference to an external file.
<configuration>
<appSettings file="ExternalWeb.config">
<add key="MyKey" value="MyValue" />
</appSettings>
...
</configuration>
http://www.devx.com/vb2themax/Tip/18880
This way when things change in the main web.config, few things must be updated.
You may also consider using templates and code generation techniques to generate a web.config for each server.
How about a "mode" appsetting key/value. This "mode" can be set to "dev", "testing", "prod", etc. Then, set the mode of the current configuration file and prefix all the settings that would change with the mode.
Example:
<add key="mode" value="test" /> <!-- possible values: dev, test, prod -->
<add key="dev.dbconnstr" value="data source=DB;userid=ABC;password=DEF" />
<add key="test.dbconnstr" value="data source=DB;userid=ABC;password=DEF" />
<add key="prod.dbconnstr" value="data source=DB;userid=###;password=###" />
Then, use a configuration class to read the setting depending on the mode.
Example:
mode = ConfigurationManager.AppSettings("mode");
CongifurationManager.AppSettings(mode + ".dbconnstr");
Doing it this way, you can have the same config file deployed to all servers, and never have to worry about tweaking each server (except of course updating the "mode" value when deploying). I would also recommend not saving the production credentials in the other configuration files, instead replace it with a placeholder.
You could create a deployment script in something like nant which loads in a web.config containing placeholders for the configuration options. This could then replace the placeholders for the appropriate environments.