A customer of mine have a Visual Studio C# solution with more than one project which uses the same ConnectionString. So how can you define your ConnectionString(s) once and share them between projects?
This is how my sample solution looks like. The “Console” and “ServerConsole” projects should use the same ConnectionStrings.

I created a XML file called “connections.config” in the solution root folder and added it to the solution via the “Add Existing Item” dialog. This file contains all my ConnectionStrings I need.

Content of connections.config:

   1:  <?xml version="1.0" encoding="utf-8"?>

   2:  <connectionStrings>

   3:    <add name="DefaultDatabase"

   4:     providerName="System.Data.SqlClient"

   5:     connectionString="Data Source=.\SQLEXPRESS;
             Initial Catalog=ShareConnection;
             Integrated Security=True" />

   6:  </connectionStrings>

After that, I add the file to all projects, which are needing the same connections. You need to add the file as “Add As Link” to ensure using the file in the shared location.

Now you see the file in your project with a little arrow on the left bottom (linked file).

To ensure the file is copied to the build output directory, you need to modify the “Copy to Output Directory” setting of the linked file to “Copy Always”.

Now write the following “connectionStrings” section in the “App.config” of your projects:

   1:  <?xml version="1.0" encoding="utf-8" ?>

   2:  <configuration>

   3:    <appSettings>

   4:      <add key="SpecificProjSetting" value="SomeValue" />

   5:    </appSettings>

   6:    <connectionStrings configSource="connections.config" />

   7:  </configuration>

And that’s all. If you now write your code, you always get the shared ConnectionString e.g.:

   1:  public string GetDbConnection()

   2:  {

   3:      return ConfigurationManager.ConnectionStrings["DefaultDatabase"].ConnectionString;

   4:  }

Individual ConnectionStrings for each developer

My second requirements, enabling each developer to have his own ConnectionStrings (they have different Instance-Names), needs only a small addition.

In addition to the “connections.config” file which is under Source Control, each developer can create his own file at the same place with the convention “connections.config.{COMPUTERNAME}” which will not be checked in. In my example my computer’s name is “NIM-50″, so the file is named as “connections.config.NIM-50″.

Edit now each project’s (Pre-Build/Post/Build) property in the “Build Events” tab with the following command lines.

Pre-build event command line:
if exist $(TargetDir)connections.config del $(TargetDir)connections.config

Post-build event command line:
if exist $(SolutionDir)connections.config.$(COMPUTERNAME) copy $(SolutionDir)connections.config.$(COMPUTERNAME) $(TargetDir)connections.config

The “Pre-Build” checks if a “connections.config” allready exists in the drop location and deletes it. If the “Pre-Build” wouldn’t be run, then the old (existing) file will not be overwritten!
The “Post-Build” checks if a specific developer configuration is found and copy/rename it to the drop location. If no one exists, the standard shared config will be used as defined in the project’s include.

If you want to run Static Code Analysis or automated Tests you need to install Visual Studio Team System on the build server. For this Team System installation you don’t need any additional licenses as far as your developers have an appropriate license to do the specific task (extract from Licensing Guide):

Conclusion:
If you (=developer) only have a Developer Edition installed and queue a new Team Build, you don’t need any additional licenses. Only if you want to modify or create such a build definition.

The build server do not need any licenses (included in Team Foundation License), only the developers who working on it!

So after installing everything, the setup shut a message that the client tools couldn’t be installed, because there’s an older version already installed.

Name: Microsoft SQL Server 2005 Tools Express Edition
Reason: Your upgrade is blocked. For more information about upgrade support, see the “Version and Edition Upgrades” and “Hardware and Software Requirements” topics in SQL Server 2005 Setup Help or SQL Server 2005 Books Online.

Build version check:
Your upgrade is blocked because the existing component is a later version than the version you are trying to upgrade to. To modify an existing SQL Server component, go to Add or Remove Programs in Control Panel, select the component you would like to modify, and then click Change/Remove.

The client tools which were installed by the Visual Studio blocking the setup tool to install the management studio etc. After some research in Google, I found the solution for this problem on the MSDN forums.

You need to start the setup from the command line with the parameter “SKUUPGRADE=1″ to force installing the newer versions of the client tools:

cmd>setup.exe SKUUPGRADE=1