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.
Related
Situation
I'm creating a project in WPF where I want to store some data in config files. Like menu Items, tree items and some other data. The ways I could implement this was by using:
XML Files
Ini Files
Integrated Settings
Databases
What is the problem
I chose the ini file approach with this library.
But if a user removes a config file I should have a default back up of my settings, so my program can run without any problem. The options to restore to the default settings that came up to me where:
Getting the default settings from the server
Creating a class that stores the default settings, when a file gets removed this class can restore it.
I think this is a dirty solution because these classes are mostly unused but are included in the project. And if I follow the SOLID and DRY approach I will end up whit +- 7 more (unused) classes.
By doing this I will also ruin the idea of getting the settings
out of my code.
Using the integrated settings from visual studio that has this already build in
I don't think this is meant for storing large amounts of data, like
tree items, menu items.
Question
How should I restore my data to default (by recreating the config file whit the default settings) when a user removes the config file? What approach should I take, or are there any that I missed?
You could include the default fallback settings in a file that you compile into the assembly as a resource.
The user won't be able to remove this one like they can remove a file in the output directory of the executable.
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 use a settings file in my project in addition to a configuration file, and I wish to move away from using the settings file in preference to the configuration file.
The settings file is the default .net application setting mechanism (ApplicationSettingsBase), and my configuration file is a custom class that I serialize and deserialize manually.
I have successfully in the past applied the NeedUpgrade/Upgrade() logic to keep settings from previous versions, but somehow it seems settings are lost non-the-less.
The difference with this project in regards to earlier projects, is that it is deployed using Click-Once.
To work around the problem, I wish to move away from the settings file all together and rather use my configuration file which is stored in a static folder (Environment.SpecialFolder.LocalApplicationData), but I do not know how I best would proceed in managing this migration/change.
Any advice is appreciated.
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.
HI,
I want to have set configuration settings for a unit test project that is only relative for one machine ( i.e build machine). So for e.g. is the unit test project is being compiled on a developer machine then use settings A from App.config, if it's compiled on a build machine then use settings B from App.config. Is there a best practice for this sort of things?
In the appSettings tag, you can add an attribute like:
<appSettings file="moreSettings.config">
Inside the 'moreSettings.config' file, you create an tag that contains key-value pairs for any of the key-value pairs that you want to override from the main App.config file.
you can use conditional compilation symbols (just same as macro in C/C++) also...
Well, i guess you could check the hostname (this should be possible in almost any language or build environment) and depending on that decide what settings to use.
However i would not advise you to "automagicly" decide to do a developer/debug build. But rather i would suggest you provide a "switch" either on comandline or in a config file. Which you than explicitly enable in your setup on the development/test machine.