Consider a group of developers working on an ASP.net web application. Each developer would like to have a private version of the web.config.
By "private" I mean that a developer can freely change the file to suit their dev/test needs at any given moment, without it affecting other team members and without ending up in source control.
How can one go about achieving this with Visual Studio 2015?
My closest solution so far is to have a "private" Solution Configuration with a matching Web.config Transformation file ("web.private.config") that's excluded from source control.
But this is not a satisfactory solution because:
a. The transformation is not run automatically when debugging (with F5). The developers need to remember to run it manually.
b. The result of the transformation ends up in the main "web.config" file which is, naturally, included in source control.
We had a very similar problem but only needed personalized versions of the <appSettings> section in Web.config.
In this situation the inclusion of an external file through configSource turned out to be problematic, as this attribute completely replaces the <appSettings>-node. So there remains no way to keep global key/values AND personal key/values for all developers. The whole section is completely replaced by the included private file.
What we need is both global and private <appSettings>. The solution we found was the file attribute. It allows to merge Web.config settings with settings from an additional file.
We ended up with a construct like this one:
<!-- Web.config with global appSettings) -->
...
<appSettings file="Web.PERSONAL.config">
<add key="BaseUrl" value="https://projectname.dev.local" />
...
</appSettings>
...
<!-- Web.PERSONAL.config with personal appSettings -->
<?xml version="1.0" encoding="utf-8"?>
<appSettings >
<add key="EmailSmtpUser" value="my.name#my.domain.com" />
<add key="EmailSmtpPwd" value="***" />
</appSettings >
If you put identical keys in both files, the Web.PERSONAL.config version will overwrite the Web.config version.
The file Web.PERSONAL.config must be excluded from Git through .gitignore .
Keep in mind:
While configSource works for ALL nodes in Web.config, the file attribute is restricted to <appSettings>.
Have web.config include an external file (via configSource) and add that file to .gitignore
The correct answer is to host your local development site in a separate location from your Visual Studio solution. You can then use publish profiles to publish changes to that location and web.config transforms to maintain a separate local config for each developer. Each developer would use a different publish profile which transforms the web.config with their own transform and deploys the transformed web.config to the publish location. You can then attach a debugger to the published site using Visual Studio's Debug > Attach To Process option.
I think there is a lot of value in standardising dev environments so that one can just download the solution and run it.
Custom, long term/permanent, developer specific configs will sooner or later lead to a subtle bug that will be tricky to find.
My solution to your problem would be to find out the reason(s) why permanent individual configs are needed and have a look if these environment specific differences can be eliminated.
Related
There are 3 environments through which my .Net web application goes namely Development, Release and Production with each having their own config and project setting files.
Assuming that the setting and config files for different environments are in one system, I want to create a small script or an application where the developer just mentions the environment type and the related setting and config files get loaded and then the application builds.
Can anyone guide me on this?
You can create config transforms and use them in publish profiles. For each configuration (Debug, Release, YourOwnConfig ...) there will be a file named by its configuration (Web.Debug.config, Web.Release.Config, Web.YourOwn.Config, ...)
The trick is that you have one complete config file, the original Web.Config, and the transforms just mention the differences to this file via XSLT transform syntax (once you create a new transform, there will be some examples in the file itself showing the syntax). For example, adding a transform for an appSettings key looks like:
<configuration>
<appSettings>
<add key="ClientSessionTimeout" value="100"
xdt:Transform="SetAttributes" xdt:Locator="Match(key)" />
</appSettings>
</configuration>
That example will replace an existing ClientSessionTimeout setting by the one specified (with value="100"). Notice how the xdt:locator specifies that the key attribute will be used to localize the setting, and xdt:Transform specifies that the attributes mentioned (here: value) will be set.
If you have applicationSettings, you need to replace the setting itself:
<applicationSettings>
<WebApplication2.Properties.Settings>
<setting name="Setting" serializeAs="String"
xdt:Transform="Replace" xdt:Locator="Match(key)">
<value>Some value</value>
</setting>
</WebApplication2.Properties.Settings>
</applicationSettings>
The differences will be for example the data source settings, other environment specific settings such as URLs to web services etc.
To create those, select a configuration such as "Debug", then right-click on the Web.Config file and you will see a context menu item "Add config transform" - click it and the Web.Debug.Config transform file will be created underneath the Web.Config. Adapt it as mentioned before; copy the entire key or setting to the transform file, then add the appropriate xdt attributes as shown above.
Finally, you can use the "Publish" function (Right-Click on the web prroject to select it). A wizard opens where you can set up a publish profile. There you can mention a configuration - like "Debug", "Release", and the ones you've created earlier.
A file publish will put the files together needed to deploy the web project and additionally perform the transformation of the Web.Config by applying the appropriate transform file (e.g. Web.Release.Config). The published config will be named "Web.Config" and contains all changes.
For trouble-shooting, and to find out more about the topic, I recommend the following links:
asp net web application: add config transform grayed out
web.config transform not working
Notice also the side-bar of Stack overflow showing more related links.
Is there a way to tell IIS to read configurations from a different file than web.config?
Why would anyone do this?
Convenience. When working with static resources like an .aspx, or .js, or an MVC view file, it is often sufficient to hit Refresh in the browser to see the effect of that change.
Also, more specific to our scenario is that we re-use some of our code-base in different flavors of the web site, their differences being defined in their respective .config files, and each of these sites run locally on our development clients.
Getting the change to a different location than the one you are actually working in is somewhat time-consuming: A Publish operation will properly compile and copy the entire web application to the target location, copying the individually changed file manually is often... fiddly.
So what I would like for to be possible is this:
I work on my project in c:\workbench\FlavMaster3000. In this folder I create the various flavors of web.config files:
web.apple.config
web.banana.config
web.cherry.config
I create sites in IIS that represents each flavour and set their directory to the same as above.
https://local-apple/
https://local-banana/
https://local-cherry/
And I would like for IIS to read each site's configurations from the respective flavor of .config.
Is this at all possible, or am I a dreamer with a hopeless dream?
-S
You can put your specific configuration in external file(s) and link those files in your web.config file as shown below. However downside is way web.config is watched for any changes in it and gets applied immediately when you save web.config, these external files will not be monitored and you will require to manually restart app pool.
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<appSettings configSource="Myconfigs/myappSettings.config"/>
<connectionStrings configSource="Myconfigs/myconnections.config"/>
<system.web>
<pages configSource="Myconfigs/mypages.config"/>
<profile configSource="Myconfigs/myprofile.config"/>
<httpHandlers configSource="Myconfigs/myhttpHandlers.config"/>
<httpModules configSource="Myconfigs/myhttpModules.config"/>
</system.web>
</configuration>
We have a whole bunch of websites with very similar web.config files.
Can you centralise the duplicate configs in 1 config file before the root directory of each website? Or is the only option machine.config?
We are looking to centralise an assembly reference in the GAC.
Structure:
Containing Directory
Website 1 Directory
Website 2 Directory
Website 3 Directory
Web.Config File for all above sites
I have not encountered a way to have inherited config files besides machine.config, app/web.config and user.config levels. But you can use configSource attribute on all config sections (ConfigurationSection based) to include a common file for example with service endpoints, client endpoints, bindings, connection strings and others. Even though VS intellisense marks it as unsupported it does work.
<configuration>
<system.serviceModel>
<services configSource="Services.config" />
<client configSource="Client.config" />
<bindings configSource="Bindings.config" />
<behaviors configSource="Behaviors.config" />
</system.serviceModel>
<pages configSource="pages.config"/>
</configuration>
Config source files must be in application's folder or any folder below. No going up or absolute paths. But there is a trick to overcome this limitation in VS2010. You need to add an existing file as a link and change its property named "Copy to Output Directory". This way your absolute path file will get copied to your application folder from where you can reference it in configSource.
In previous versions of VS it is also possible but in a less elegant way - copy file in post build event.
If you are looking mainly to centralize WCF settings there is another option: in-code configuration. Huge advantage of this is you get compilation-time check and refactoring support from VS. If this does not sound like much I can assure you that in a bigger WCF project, config file management is a nightmare especially when you need to change something. With this approach it is also very easy to centralize WCF settings by just creating a common assembly where all services, endpoints, bindings etc. are defined. Disadvantage is that you loose possibility to change WCF settings without recompilation. But if those settings do not change very often it is a tempting alternative.
You can use the web.config located in
%SystemRoot%\Microsoft.NET\Framework\<versionNumber>\CONFIG\Web.config
Or if in IIS you configure your Containing directory as a main web site and then put your website directories as applications, you can put the web.config in the main web site to have the structure you mention.
if it is cached, what happens if I use multiple web.config in multi-level folders
They all get cached.
Configuration is read once, at startup. With web.config, IIS watches for file changes and restarts the application.
OK, so ya'll are missing a KEY feature in the Web.Config file's area.
Yes, web.config is cached and changing contents of the file will restart your web app. And, all your connected users will not be happy, too, because they'll need to "reconnect" a-new, possibly losing desired information.
So, use an EXTERNAL custom file for your AppSettings, as follows:
<appSettings configSource="MyCustom_AppSettings.config"/>
Then, in the file MyCustom_AppSettings.config file, you have your settings, as such this example has:
<appSettings>
<!-- AppSecurity Settings -->
<add key="AppStatus_Active" value="Active"/>
<!-- Application Info Settings -->
<add key="AppID" value="25"/>
<add key="AppName" value="MyCoolApp"/>
<add key="AppVersion" value="20120307_162344"/>
</appSettings>
Now, if you need to add, change, or remove an AppSetting, when you change it in this file the change is nearly instant in your web-app BUT (and here's the BEST part), your app DOES NOT RESTART!
Everything stays kosher except those settings you've added/modified/removed in the external .config file.
And, yes, the same thing can done for the section as follows:
<connectionStrings configSource="MyCustomApp_ConnectionStrings.config"/>
and the file MyCustomApp_ConnectionStrings.config has all the connection strings you need. Change a connection string in the external .config file and it starts getting used right away and with no web-app restart.
The configSource setting(s) are great when you need to deploy to development, testing, and production on different boxes and need settings pertinent to that given box/environment.
So, now ya know (something that's been around for 7+ years).
It's That Simple. Really.
KC
Web.config (excluding external config files) is read when the application loads. Some config settings have a cascading behavior. For example, the system.web/authorization section can be overridden by configs at deeper levels.
ASP.NET monitors the web.config for changes. When it changes, the web application is forced to restart. Moral is that web.config settings are cached for the life of the application.
I need to change my connection string in the web.config file based on an environment variable (for different enviornments, like dev/staging/production, etc). I have seen other solutions that use build tasks to accomplish changing different configurations, but haven't been able to find something that will let me change my connection string based on an environment variable. Does anyone know of any way to do this?
We make use of the configSource attribute for the appSettings and connectionStrings elements in the web.config.
Basically, we have the same web.config file for all of our environments: dev, qa and production.
Then we utilize seperate "environment specific" files.. For example...
In web.config:
<?xml version="1.0"?>
<configuration>
<appSettings configSource="local.appsettings.config" />
<connectionStrings configSource="local.connectionstrings.config" />
</configuration>
Then we maintain the following files:
local.appsettings.config.development
local.appsettings.config.qa
local.appsettings.config.production
local.connectionstrings.config.development
local.connectionstrings.config.qa
local.connectionstrings.config.production
Since we pre-compile all of our asp.net applications before deployment, we've got a custom msBuild task utilized by our CI solution that copies the right configuration files (based on the target environment) to the proper .config file...
So, if we are deploying to dev, local.appsettings.config.development -> local.appsettings.config
If we are deploying to qa, local.appsettings.config.qa -> local.appsettings.config
This allows us to keep the core web.config the same across all of our environments.
How about having two connection strings and another variable, like "isTesting" in your web.config, then based on the value of isTesting pick which connection string to use?
you can also use config sections, and based upon server name switch between sections. this way you can have keys named the same.
link text
You can set a web.config for each environment in the configuration manager using prebuild events. I have tried this with excellent results.
http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx
When you have debug and build you can have local/preproduction/production... etc