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
Related
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 have two separate solutions with web projects. I need to use one app setting in both. I don't want to duplicate this value in two web.config files - want to store it in one place (and not in machine.config!). These two web projects have other different appSettings and their web.config files are completely different.
Is it some way to share somehow just one appSetting between two web projects?
This link
explains how you can refer to another config file for some of the settings. The config file doesn't have to be stored in the same folder as your web.config file so you can share it with other projects.
I'm working on a project with several environments (Local,Development,Main,Prod,Live) that have several config files (Web, ConnectionStrings Windsor, Smtp, Appsettings, Nlog, etc).
The current strategy used is to have one of these config for each branch and to maintain the configs by hand and not to merge any changes.
What are the more elegant options for storing and deploying config files in this sort of set up?
Generally I tried to keep most of these settings in the appSettings (even though I know that's not the "official" right place for them). Then I break the appSettings out into an environment.config file, and have the appSetting element in the web.config reference that through the configSource attribute.
When I setup a new environment, I manually setup the environment.config file for that environment. When, when I deploy a new release, I exclude the environment.config file from teh deployment so that the environment-specific version stays in place.
This lets you deploy new copies of the web.config to include project-related changes, while keeping all of your truly environment-specific settings in a seperate place.
An elegant solution is to use WebDeploy (from Microsoft) for the deployment of your web app. When you run the deployment, you can specify a site specific parameter file which will be used the replace several values in the web.config file.
For deployment, WebDeploy uses a deployment packge, which Visual Studio or msbuild can create.
That way, we have a single deployment package that we can first deploy on a test system, run through several tests and then, when it passes the test, deploy without changes on several servers. Each server has its local parameter file that hardly ever changes and contains the site specific values.
store them on a file server that has the same name in all environments. I am not familiar with all of the configs, but most have ways of doing this. The only problem with this approach is usually dev/local which often share a file server so you have to change the local by hand.
If you actually can't point the configs to a file server, a less elegant solution would be to pull them down via a bat file at deployment or start up. seems like there are alot of options rather than maintaining by hand, that is error prone.
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