I am working on a C# 4.0, WPF 4.0, SQL 2008 project and I do work at home and in the office. I just setup SubVersion using Visual SVN per the recommendations found in other ques
.NET has a way of overriding settings in one config file from those in another using the file
attribute. We usually do something like this:
web.config
<configuration>
<appSettings file="web.custom.config">
<!-- your default settings here -->
</appSettings>
</configuration>
web.custom.config
<appSettings>
<!-- override stuff from root web.config here here -->
</appSettings>
By convention, we set up our source control system [SVN] to ignore any custom.config files. This allows us to check-in the core, default settings while still allowing each developer to manage environment-specific settings.
Note: this only works with the <appSettings>
key. If you're storing connection strings in the <connectionStrings>
key, consider moving those settings to appSettings instead.
See http://msdn.microsoft.com/en-us/library/ms228154.aspx
If you really want to automate this fully, you could do something like this:
First, store the settings for the different environments in source control, but not the actual configuration file. For example:
configfiles\app.config.mikeb_home
configfiles\app.config.local
configfiles\app.config.development
configfiles\app.config.staging
configfiles\app.config.production
Then in your build configuration, you can add a step to copy the right config file to your root app.config. E.g. with a 'pre-build event' (command line script) based on 'environment' parameters (computername, username, ...). You can probably achieve the same thing by adding some msbuild commands in the .csproj file.
However, is all this really worth it? TortoiseSVN has a feature called the 'ignore-on-commit' list, which helps you prevent accidently committing a locally changed file that shouldn't be committed (in the commit dialog, right-click on the file => Move to Change List -> ignore-on-commit). May be slightly annoying if you actually need to change something else in the .config file, but still.
Simple: Don't put the connection string in code, read it from configuration data somewhere. And then just don't put that configuration data in Subversion.
In an app that I'm working on now, we store connection string information in the Windows registry, in HKLM\Software\[OurProduct]\Database.
I think the ideal solution would be to use something like the web.config transforms that are being added in Visual Studio 2010. Unfortunately as far as I can tell these are only available for web.config files.
Can't you change the .config at home and not check the change to the connection string back in?
Holding connection string information in code is bad practice (anyone can use ildasm.exe and see all the strings in your code).
This kind of information should be in configuration which you have better control over.
Additionally, .NET supports encryption of the connection string section, if needed.
you can use settings to define more than one connection string. just double-click Settings.settings from Solution Explorer->project->Properties. then you will see the combobox that contains types of settings. choose ConnectionString then enter the connstr.
then you can get the connstr with below code
using System.Configuration;
using test.Properties;
namespace test{
public partial class mainForm : Form{
public mainForm()
{
InitializeComponent();
}
private void mainForm_Load(object sender, EventArgs e)
{
string connectionStr = ConfigurationManager.ConnectionStrings[this_index_is_up_to your_algorithm].ToString();
}
}
}