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.
Related
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.
I have an asp.net application that sets the configSource attribute on the rewriteRules element in web.config to point to a separate config file:
<rewrite>
<rules configSource="App_Data\Config\RewriteRules.config" />
</rewrite>
My web app makes edits to the RewriteRules.config file programmatically, but my web app does not pick up the configuration changes after the file is edited and saved.
I have tried calling HttpRuntime.UnloadAppDomain() after editing the file. This successfully restarts my app domain, but the changes in RewriteRules.config are still not picked up. I have tried adding RestartOnExternalChanges="true" to the rewrite element, but this is apparently not supported on the IIS rewrite module. I have also tried ConfigurationManager.RefreshSection("rewrite/rules") but this does not seem to have any effect. The only way I can get the changes to take effect is to edit and save the main web.config file, but I am trying to avoid doing this programmatically for security reasons.
I am confused as to why HttpRuntime.UnloadAppDomain() does not cause external config files to be re-read. Is this expected behavior? Does the config file cache somehow exist outside the bounds of the app domain? Is there any practical way to achieve what I am looking to do?
Dude, the problem with your case is, related configSection definition is not marked as restartOnExternalChanges="true" in definition. For example; we created a custom config section for storing application urls in an external file and we create a section definition in web.config file like
<section name="pageUrlFormats" type="Kahia.Web.Configuration.PageUrlFormats.PageUrlFormatsSection, Kahia.Web" restartOnExternalChanges="true" requirePermission="false" />
so that asp.net knows if any change occurs in related file:
<pageUrlFormats configSource="Config\PageUrlFormats.config" />
application domain restarts. This goes same for all config section definitions, including UrlRewrite module's definition.
What you have to do is, find definition of related module. In this scenario, it is at apphost.config at C:\Windows\system32\inetsrv\config\applicationHost.config
In that file, look for rule section definition, it starts like
<section name="rules"
You have to add restartOnExternalChanges="true" attribute to that config file.
IIS7 configuration system uses the same syntax as the .Net framework configuration system, but is a different implementation that has some behavior differences. The restartOnExternalChanges thing is a feature of the .Net framework configuration system that is not supported by the IIS7 configuration system. The url rewriter module uses the IIS7 configuration system.
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>
I have two web application. Their folder hierarchy in server is like that.
first one is : .../firstapplitaion
second is : .../firstapplication/secondapplication/Default.aspx
At first can i run them with just firstapplication's web.config file? secondapplication's web config hasnt any special things.
Thanks for your helps..
One way would be to have a section in your web.config files point to an appropriate file, like this
<configuration>
<appSettings file="C:\MyCommonFolder\MyCommonAppSettings.config">
</appSettings>
</configuration>
Hope that helps
If the second app's web.config file is the same why bother to even run them as seperate apps? Why not just make them one app that uses the same web.config? Or were you trying to split them into seperate app pools?
What I have done in a similar situation was to have each site contain it's own seperate web.config but to move all of the shared pieces into my Machine.config. For me it's locatd in the C:\WINDOWS\Microsoft.NET\Framework\vX.X.XXX\Config folder (I would suggest backig it up first). Because of the way the config files work you can put settings in your machine.config and your websites will inherit these settigs. So put any shared settings there, with very unique names, and you should be set.
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.