I have a folder containing several websites, all using the same assemblies in the GAC. Each website also contains some 'custom' assemblies of their own that refer to the common assemblies.
There is a web.config in this folder, defining common settings for the sites, including the assemblies to load in a <system.web>/<compilation>/<assemblies> element.
What I want to be able to do is add a <runtime>/<assemblyBinding> section to redirect requests from the older 'custom' assemblies to the newer ones installed in the GAC. (Unfortunately, using machine.config or the GAC redirection policy aren't options as this will affect other sites.)
It seems that the <assemblyBinding> section is ignored unless it is in the website's own web.config, or the machine.config.
I've already come across the <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"> problem so I know it's not that.
Does anyone know if this is what is supposed to happen or am I missing something?
It is supposed to happen. You did nothing wrong.
for more information, please take a look at
http://msdn.microsoft.com/en-us/library/2fc472t2(vs.71).aspx
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.
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 run into an issue that when my web application's web.config compilation debug is set to true I am getting a vulnerability error on a security scan.
What I want to determine is if there is a way to have some type of web.config conditional block change the debug setting to use the correct value on debug builds and release builds. I have read that setting the property in each web page itself will do this and don't know if this is in fact true and are there any problems with this?
I would suggest <deployment retail=”true”/>.
You put this element into your machine.config on the production server and it overrides debug=”true” in your web.config and pages. In other words, you can happily use the debug and trace functionality on your developer machines but can be sure it is turned off on the production server. Scott Guthrie recommends this as best practice.
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.