We have 1 settings file with the customer settings for each costumer, but the problem is that we have to change lots of settings values when releasing a new version for each costumer, as we develop using the test settings. So, its a totally mess.
Whats the best solution for this?
Having one settings file and app.config for each costumer?
Saving the configurations into the database?(we would still have the connection string settings)
Each costumer cant see the settings from the others..
We use a Configuration Transformation for this and have multiple Build (Release) configs like
Release-Internal
Release-CustomerA
Release-CustomerB
You can have one "base" config file and just replace the values you need for the specific configuration.
Your file structure would look like this afterwards
app.config
app.Release-Internal.config
app.Release-CustomerA.config
app.Release-CustomerB.config
We usually use this for the connection strings and some specific view settings.
Visual Studio only has nativ support for ASP.NET projects (for whatever reason), but there are multiple Plugins to enable this for other .NET projects.
I can recommend Configuration Transform (I like this one better) or SlowCheetah.
I would like to use app.config files for settings, but I don't want to have to select different build configurations to select which settings to use, I would rather everything build in release and then just the app.config file be different when the application is deployed.
What is a good way to merge two xml files together so that I can deploy the correct settings to the correct environment? I have found several solutions that are based on selecting different build configurations and the transform happens at build time, but I want the transform to just be from a command line utility that my deploy script can run
At my company, we use the Web Config Transformation Runner, available on GitHub. It may be invoked directly from the command line, a bit like this:
D:\Utils\WebConfigTransformRunner.exe App.config App.production.config App.config
We've incorporated this into a larger packaging and deployment process to handle deploying to our various environments.
I am doing some research on how to make web.config dynamic per environment and brand. We have web.config different for different environments and brands.
Right now we make copy of it store a separate files and finally pick it manually and deploy.
I am finding various arcticles to do this and one the below has one solution.
http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx
I don't want any code or anything like but need some references if there are any other best industry practices
See http://msdn.microsoft.com/en-us/library/dd465326(v=vs.110).aspx for web.config transformations. Same concept. You have a base config file and then have specific nested config files per environment, brand or both. Depending how you deploy your application can affect how many web.config you have. In newer visual studio you cannpreview the changes as well by clicking on the nested web.config in solution explorer
App.config transformations aren't supported out of the box but with some msbuild events that's how wendo these ones
I have an ASP.Net web site (ASPX and ASMX pages) with a single web.config file. We have a development version and a production version. Over time, the web.config files for development and production have diverged substantially.
What is the best practice for keeping both versions of web.config in source control (we use Tortoise SVN but I don't think that matters)? It seems like I could add the production web.config file with a name like "web.config.prod", and then when we turnover all the files we would just add the step of deleting the existing web.config and renaming web.config.prod to web.config.
This seems hackish, although I'm sure it would work. Is there not some mechanism for dealing with this built in to Visual Studio? It seems like this would be a common issue, but I haven't found any questions (with answers) about this.
I use nant for my builds. On the SVN I have a web.config.template that contains parameters that are expanded using a properties file. Each environment has its own properties file with different values.
So in short, I don't have the web.config on the SVN, but a template instead.
Something like this
http://www.cptloadtest.com/2007/09/22/Managing-Multiple-Environment-Configurations-Through-NAnt.aspx
NAnt: http://nant.sourceforge.net/
We use the exact method you describe, it works great, for example we have:
web.config (for local development)
web.Dev.config (build server, builds on check-in)
web.QC.config (testing environment)
web.Prod.config (production)
The build script for each environment just deletes the web.config and renames the appropriate one in it's place. Doing this way allows you to easily source control all of them and very quickly do a diff and see what may be different between environments. Updating a config value across the board is much easier as well...the next time it's pushed to that environment, it'll get the new config.
Visual Studio 2010 adds a new feature called XDT Transforms, which automatically combines multiple Web.config files for different configurations.
However, VS2008 does not include any such feature.
I'm building an application that is used by several different customers. Each customer has a fair amount of custom business logic, which I have cleverly refactored out into an assembly that gets loaded at runtime. The name of that assembly, along with a number of other customer-specific settings, are stored in the application's configuration file.
Right now, here's what I have to do in order to debug the application for customer foo:
Go to the filesystem in my project directory and delete app.config
Copy app.config.foo to app.config.foo - Copy.
Rename app.config.foo - Copy as app.config.
Tell Windows that yes, I want to change the file's extension.
Switch back to Visual Studio.
Open the Settings.settings item in my project.
Click "Yes" 13 or 14 times as VS asks me if I want to use the new settings that have been changed in app.config.
Close Settings.settings.
Okay! Now I'm ready to debug!
It seems to me that the rigamarole of opening Settings.settings is, or ought to be, unnecessary: I don't need the default values in Settings.cs to be regenerated, because I don't use them. But it's the only way I know of to make VS aware of the fact that the app.config file has changed, so that the build will copy it to the output directory.
There's got to be an easier way of doing this. What is it?
You can also let Visual Studio automate Robert`s approach by:
Define a Build Configuration for each client
In the post build event, simply xcopy app.config.xxx to your bin folder. Where XXX is the name of a Build Config accessible in VS. Something like: xcopy app.config.$(ConfigurationName) $(OutDir)/app.config
VS will drop a distinct build for your clients in separate folders, aolong with the proper config file.
bin/Client1/
bin/Client2/
You can refer this post for some good practices : Managing Multiple Configuration File Environments with Pre-Build Events
Thinking about the mess of managing multiple configuration files I made this tool: http://envride.codeplex.com/
Its purpose its exactly to make it easier to manage multiple configuration files in an automated way. I would be very pleased if you would take a look at it.
A couple of people suggested using multiple VS configurations, which I think would have worked, except that it would require me to rebuild the solution every time I switched between configurations.
What I did instead seemed a little stupid while I was doing it, but I've been using it for nearly a year now and it works extremely smoothly. In my project directly, I create a separate app.config.XXX file for each customer. The actual app.config file is used solely to generate Settings.cs - it has all of the correct setting names and their default values. It doesn't get copied to the build directories, ever.
Then I wrote a little program that lets me select a customer, and that simply goes through the directories for each project and, if I selected customer XXX, copies app.config.XXX to bin\debug\myprogram.exe.config and bin\release\myprogram.exe.config. As long as this program knows where the root of the solution is (I have to be a little careful whenever I branch the code), it works like a charm.
This thread is too old to represent current tools in VS.
You can use an addon that acts similar to web.debug.config but for app.config.
https://marketplace.visualstudio.com/items?itemName=GolanAvraham.ConfigurationTransform
And for the same app.config transformations without addon.
https://www.linkedin.com/pulse/multi-appconfig-visual-studio-2017-benjamin-davis/
You may opt to define multiple Visual Studio solution configurations, one for each customer, and have customised MSBuild targets for your Windows app project.
I have documented the steps of how I handled this here. Multiple app.config files for deploying to different environments
After a little digging and work around I got my Test project working with multiple configurations,
In the Configuration Manager, create the configurations you need
Copy paste your app.config and add the name of the configuration, in my case is AHI, FIV, MGC, so my config files look like: App.AHI.config, App.MGC.config, App.FIV.Config. You can name it how ever you wanted, but keep the same convention
Add a Post-Build event. In my case it would look like: xcopy $(ProjectDir)app.$(ConfigurationName).config $(TargetDir)$(TargetName).dll.config /y
here is my post, so you can read it with more details
Running a Test Project with Multiple Configurations