views:

164

answers:

5

Is there a way, in the web.config, to specify machine-specific values? For example: in production I want the <customErrors> node to redirect to specific pages for displaying user-friendly error-handling pages, but in development, test, and staging, I want <customErrors mode="Off" /> so I can see as much detail as possible.

Is this currently possible?

A: 

<customErrors mode="RemoteOnly"> will do that for you.

Nathan Taylor
Only if the test and stage environments happen to be the dev PC, which I doubt.
Fredrik Mörk
True. Small business mindset here. :)
Nathan Taylor
A: 

If you make

<customErrors mode="RemoteOnly">

then you will see detailed error messages on the Web Server machine but friendly error messages (that you will need to specfy in web.config) in all remote machines.

Ganesh R.
A: 

Isn't that what the .config files are for? Different configurations for different environments? With websites, we always have different web.configs for each environment (referencing different connection strings etc. . .) Nathan Taylors answer is correct for your specific problem though.

andrewWinn
The point is that the website is the same, we're just moving between dev, test, staging, and prod servers. If I can get the configSource attribute to work where the sub-config file is outside of web root, then I can put machine-specific files -- that never need to be updated -- on the servers in question and the web config just simply looks one directory up for the details needed for the machine it's on.
+1  A: 

With ASP.NET 2 and above, a lot of the config elements now support a "configSource" attribute, that allows you to replace the contents of that section with an external file. this could allow you to have general settings in the main web.config and then separate files for the sections you know are going to change per environment.

As Nathan points out, in this instance you could use the RemoteOnly mode, which will display full errors when you are browsing the site on "localhost" - if you aren't developing on LocalHost then this won't help you.

VS2010 will add a new feature where you can modify the config file based on the build target, so a release or production build could automatically set this to "On", while debug or staging might set this to "Off".

Another option is to hook into the Application_Error event in the global.asax, and if the user is logged in as some sort of admin, output the stack trace, otherwise display the error page.

Zhaph - Ben Duguid
Okay, so when I do something like <customErrors configSource="..\customErrors.config" /> it doesn't work. I love the idea of the configSource attribute, but if I can't reference a file outside of relative root (just one folder up would be adequate) then I'm back to manually tweaking the web.config file when I push to the dev and test servers.
By the way, I've tried the following sytanxes without success as well:<customErrors configSource="../customErrors.config" /><customErrors configSource="C:\inetpub\customErrors.config" />
No -- not browsing on localhost. I'm publishing to a test server and it doesn't help Q/A to tell me they are getting a "generic yellow screen without error info."
Nevermind. I see that the file referenced in configSource must be within the relative root ( http://stackoverflow.com/questions/569117/net-config-files-configsource-outside-the-application-directory-folder ). Unless there is a wildcarding scheme that works in webConfig then I'm just going to have to manually tweak the web.config on each server. ScottGu: can't you get someone to fix this???
Sorry, yes, it needs to be within the application - and to be honest, the VS2010 feature only really helps if you're doing a different build for each environment, and that could cause other problems (namely that the build that you put on production hasn't been through QA...). The thing to do is to exclude the external file from source control/deployment scripts, and add/generate one separately.
Zhaph - Ben Duguid
A: 

I'm writing and accepting my own answer because there isn't an answer to the question as I asked it. For the path:

C:\inetput\wwwroot

where wwwroot is relative root, my goal was to put the machine-specific instruction for <customErrors> in the inetpub directory so that XCopying new code automatically picked up established machine settings in the external config file. It might be possible to do this by editing the machine.config file, but that's too low-level of a solution (requires managers' signatures on paper before the server admins will do this).

So I'm simply going to stick with the status quo of editing the web.config files for the dev, test, and staging servers.