Normally, in a .NET application, you store your database connection strings in the app.config.
For a single .exe, there's a single .exe.config. And we're using Entity Framework, which defaults to using a .config setting that matches the DbContext name. Which all works fine, so long as you follow the common pattern of having a single instance of an application talking to a single database.
But our problem requires we have multiple instances of our application, each with its own distinct database connection.
Possible solutions:
- Create multiple copies of the .exe, each with its own copy of the .config, and put a different connection string in each. Advantage? No coding changes. Disadvantage? Maintaining all the different copies, making sure they all get updated, etc.
- Keep one copy of the .exe, with one copy of the .config, and put multiple connection strings in the .config. Then pass a command-line argument to the program that selects which connection string to use. Advantage? Only one .exe to manage. Disadvantage? Coding change, likelihood that someone's going to mess up the command-line arguments.
- Some other brilliant idea, that someone here on Stack Overflow is going to point out to me.
Any ideas?
I'm sure people have dealt with this issue, before. Is there a common way of handling the issue?