We Keep Coding

Proper way to manage test/prod connection strings in .NET web.config file [duplicate]

This question already has answers here:
Using different Web.config in development and production environment
(10 answers)
Closed 5 years ago.
I have the source code of an application that I maintain. In my web.config file, I have connection strings for both my test and production databases as follows:
<add name="conn" connectionString="Data Source=TestDBServer; (etc...)">
<add name="conn" connectionString="Data Source=ProdDBServer; (etc...)">
Whenever I am in test, I just comment out the production connection string and vice-versa. For example, when I finish testing, I comment out the test connection string and uncomment the production connection string and then deploy.
I am very early on in my career as a developer, but it seems to me that there must be a better or more standard way to handle this. What should I do?
Edit
Guilherme Lofrano Corneto linked an identical question that completely answers my own question. I have since marked mine as a duplicate. Here is the link:
Change connection string from development to production when publishing

Visual Studio can automatically transform your web.config based on your currently active build configuration. So you should have a build configuration "Test", "Dev", "Prod" etc. (whatever you need for your workflow).
Then you can right-click on your web.config and click "Add transform". This creates a new config like web.Prod.config where you can overwrite your config values. When building with a specific build configuration, visual studio will automatically overwrite the default web.config with your corresponding transformation.
If you need to apply such transformations to other files than the web.config you might want to check extensions like "SlowCheetah - XML Transforms"

You can follow the following steps to transform web config file during deployment.
Here is a short summary:
1- Set your development connection string in the web.config file. Should look similar to this:
<connectionStrings>
<add name="ConnStringDb1" connectionString="Data Source=TestDBServer; (etc...)" />
</connectionStrings>
2- Expand your web.config file and open web.release.config
3- Use the Replace function to replace the connection string with the one for you want for deployment. You can use xdt:Locator="Match(name)" attribute to match it with the name of the connection string (ConnStringDb1) in this example:
<connectionStrings>
<add name="ConnStringDb1" xdt:Transform="Replace" xdt:Locator="Match(name)"
connectionString="Data Source=ProdDBServer; (etc...)" />
</connectionStrings>
More information on transformation syntax in web.config.

My team usually keeps the "dev" setup as the one in TFS as the default. It helps if all team members install the same SqlServer "instance" so if does not differ from dev to dev.
Example :
"localhost\SqlServ2014Stand
or something like that.
For deployments to QA, Staging, UAT, Production (whatever you call them)......we write wix installer(s) (one per product) and we handle the xml-transforms in the wix project. This is what will change the connection string (or anything else) for the different environments.
You may want to look at a CI server like CruiseControl.NET or Jenkins or TFS or something. This is what will build your code in a consistent way. This takes a little time to setup. If time if the main factor, I would try Jenkins.

web.config, app.config priority / dependancies and usage on compilation

Just a quick question. I have a solution splitted in multiple projects. In one project, I have the database interactions and my EDMX. In this project, I have my app.config file with some connections strings.
This project, is imported as dependancy in a Web project. In this one, I have my Web.config where are defined (or "overriden") connections strings.
I'd like to know what are the mechanisms used to configure the database connection. From what I understood, the Web.config has all priority over App.config. But what I'm wondering is, is the App.config in dependancies projects used at compilation time ?
For instance :
Project A => app.config :
<connectionStrings>
<add name="A" connectionString="myConnectionStringA"/>
<add name="B" connectionString="myConnectionStringB"/>
</connectionStrings>
And the same in Web.config but with :
<connectionStrings>
<add name="A" connectionString="myConnectionStringC"/>
<add name="B" connectionString="myConnectionStringD"/>
</connectionStrings>
Which one will be used to define the connection to the EDMX ? In one hand, at compile time, logically it would be A & B used to define it, and C & D would be used at runtime.
But i'm not sure about it and for me, once the dll is "configured", I don't see how can C and D be used instead of A & B.
Could someone explain it to me please ?
Thanks !

The config file that is used at runtime is the one related to where you are launching your application. If you launch the projectA it will be the App.config file.
Actually it will be the file generated by the compilation on the proper directory "Debug" or "Release"
When you run your web project it will be the Web.config file there.
The dll isn't "configured" with the values from the config file, they are read when the application starts running and this will depend on the application that is running.
That is why if you change the values they will change when you relaunch the application without any need to recompile the project.

When designing your entities in Visual Studio, the connection string that is stored in the app.config file of the project is used.
Even though you add a reference to the project from the web project, the app.config of the referenced project is not used at all in the context of the web project. Of course, it can be used as a blueprint when adding the connection strings to the web.config.
The config file that is relevant to the web project is the web.config. So when running or publishing the web project, the settings that are used are the ones in the web.config.
They do not override the settings of the app.config in the sense of a fallback like "if the connection string is not configured in the web.config file, then I use the ones stored in app.config".
It is required that you add the connection strings that you want to use when running the web project to the web.config file, otherwise you'd encounter an error if you used the Entity classes.
For details on configuring ASP.NET web applications, see this link.

But i'm not sure about it and for me, once the dll is "configured", I
don't see how can C and D be used instead of A & B.
The config values are fetched when the progam is running, not when it is compiled.

How to open specific .config file in multi project solution?

Solution that I am working on is made of number of projects, one of them is start-up project(Windows Forms, .exe project) and has app.config file tied to it. At least one of the project(all other projects are .DLLs), that deals with database, will also needs to read app.config settings (to read db connection string). I want to centralize all of the application settings in one app.config file.
My questions are:
From what I understood, application configuration files are created per projects, not per solution ?
To access the app.config from DLLs should I use ConfigurationManager.OpenExeConfiguration(string exePath), where string exePath is the location of .exe for start-up project ?

Config files are connected to application domains, not DLLs. You can access your appication's (let's say web application or console application) configuration directly with ConfigurationManager class (OpenExeConfiguration not required).
If you need different connection strings in different part's of the application, you can add multiple connectionstrings in your configuration
<connectionStrings>
<add name="Connection1" connectionString="Data Source=..." />
<add name="Connection2" connectionString="Data Source=..." />
</connectionStrings>
and access them by name:
var connectionstring1 = ConfigurationManager.ConnectionStrings["Connection1"].ConnectionString;
var connectionstring2 = ConfigurationManager.ConnectionStrings["Connection2"].ConnectionString;

Visual Studio creates an app.config for each project, but only to provide a place to store configuration items for that assembly (since it could be used by multiple executing assemblies). Those configuration items should be incorporated into the app.config of the executing assembly.
You can add code to pull from multiple config files, but it's cleaner just to put them all in one app.config for the executable.

You need to copy all the project specific configuration (like connections strings etc.) into the the main app.config.

web.config issue in ASP.Net

I am using VSTS 2010 + ASP.Net + C# 4.0 to learn someone else's code for a WCF application. I find besides Web.Config, there are also Web.Debug.config and Web.Release.config. I searched the content of Web.Config, but cannot find any reference to Web.Debug.config and Web.Release.config. However in VSTS 2010 IDE solution explorer, I find there is an arrow pointed from Web.Config to Web.Debug.config and Web.Release.config -- so seems there is reference relationship. It makes me confused.
In all 3 config files, there are identical items with different values, for example, in web.config, there is connection string DBConnectinString defined in this way,
<connectionStrings>
<add name="DBConnectinString" connectionString="data Source=10.10.10.123;uid=foo;pwd=foo;database=FOO" providerName="System.Data.SqlClient"/>
</connectionStrings>
And in Web.Debug.config, there is connection string DBConnectinString defined in almost the same way with different values,
<connectionStrings>
<add name="DBConnectinString" connectionString="data Source=10.10.10.124;uid=foo;pwd=foo;database=FOO" providerName="System.Data.SqlClient"/>
</connectionStrings>
My quesiton is,
what is the relationship between Web.Config and Web.Debug.config/Web.Release.config?
Why define the same item with different values in Web.Config and Web.Debug.config/Web.Release.config?

You have different config files for different settings. Consider Debug as your local environment settings, like connectionstrings to the testserver, debug variables on, etc. The Release settings would contain settings like the connectionstring for the production server.
In the top bar, next to the run debug should be a drop down, containing all available settings. You can also add some.
This settings are useful for oneclick-deployment like the new WebDeploy with VS2010
Edit:
This link How to use web.config transforms to replace appSettings and connectionStrings? should show you a basic walkthrough about web.config transforms

This is new feature in Visual studio 2010. It allows you to have diffrent config files for you build configuration schemes. So that, when you build in debug mode it will include the Web.Debug.Config file, the same when you build for release.
This allows you for example to maintain diffrent configs for your database - one for your dev environment and for your live environment.
Hope that helps!

Can we share some contents of App.config between projects?

I have two independent projects in my Visual Studio 2008 solution. Both has its own App.config. But in one project, I need one or two properties defined in another project's App.config. Is it possible to share part of the App.config contents from other project?

Yes - of course. Any configuration section can be "externalized" - e.g.:
<appSettings configSource="AppSettings.DEV.config" />
<connectionStrings configSource="MyConnection.config" />
or
<system.net>
<mailSettings>
<smtp configSource="smtp.TEST.config" />
vs.
<system.net>
<mailSettings>
<smtp configSource="smtp.PROD.config" />
Any configuration section can be put into a separate file that can be shared between projects - but no configuration section groups, and unfortunately, it's sometimes a bit tricky to know which is which.
Also, in some cases, Visual Studio will complain (using red wavy underlines) that the "configSource" supposedly isn't valid - but it is - it's defined on the ConfigurationSection object in the .NET config system.
UPDATE:
another feature that hardly enough developers seem to know and use is the ability in Visual Studio to add existing files from a different project as a link:
With this, you can add links to files into your local project, and they'll always be kept up to date. Great productivity booster if you need to do some file-level sharing (like for common configuration files or such)!

Try this:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings file="PROD.config">
<add key="common.Currency" value="GBP" />
</appSettings>
</configuration>

Only the "running" app.config is used, but you can go external like marc_s says.
You can also create a .Settings file that's "shared". Go to the "shared" project properties, the Settings tab on the left, create a setting with Application scope, and set the Access Modifier on top to Public. In your other project you can then use ClassLibrary1.Properties.Settings.Default.SettingName to access it. It will be strongly typed, but you may need it at compile time.

Something I like to do, especially when trying to coordinate ServiceModel elements between libraries and tests is to use configSource to fragment the config in the target library and simply link/copy always the fragments in my test projects.
That way I only maintain in one location.
You could take it one step farther and simply have a common directory in the solution and link the fragments in all projects.

In that situation, I would think using a Database to store some configuration data would be ideal. Each app does its own thing, but they look to a shared database to get those common pieces of information.
EDIT: I spoke too soon! Looks like both the OP and I learned something about config files =D