title: Server-Specific web.config in website hosted from shared drive
body: <p><strong>Background Info: File Replication is Lame</strong></p>
  
  <p>Currently, we have a massive, high-traffic ASP.NET web application load-balanced across 8 different IIS servers.  Due to the nature of the site, minor changes to .aspx files and .ascx controls happen frequently throughout the day, and after being tested and published to live, are replicated out to each of the public webservers through xcopy deployment on a scheduled basis every 10 minutes.</p>
  
  <p>Of course this is incredibly inefficient, as each server must have a redundant copy of the entire site, and we would like to eliminate the 10-minute publishing lag.</p>
  
  <p><strong>Possible Improvement: Hosting from Shared Storage</strong></p>
  
  <p>We now have the option to use centralized storage with an iSCSI interface to host the entire site centrally, with each server believing that the remote storage is a local drive.  Publishes would be instantaneous and system-wide.</p>
  
  <p><em>Note: Hosting the drive off a UNC share is not possible, as there are so many different directories in the site structure, each requiring a FileSystemWatcher for ASP.NET to monitor for changes, that the SMB maximum command count is quickly reached.  Yes, we know about the MaxCmds and MaxMpxCt registry settings.</em></p>
  
  <p><strong>The Problem: Web.config changes trigger massive recompiles</strong></p>
  
  <p>The problem we forsee is that certain changes to the file system structure can cause nearly every compiled .aspx or .ascx to have to recompile, causing queued requests and a perception that the server is down.  Most resources are not used system-wide and so recompiling them on a change causes hardly a blip in resources.  A global master page used by all pages on the site can cause this, but this can easily be managed by code.</p>
  
  <p>The primary culprit is the web.config file.  Changes to the web.config file cause the entire web application to recycle, and recompilations to occur.  So, we currently don't replicate web.config changes.  Any web.config changes requires bringing the web server off the load balancer, applying (and testing) the changes, and then warming the server up with junk requests before it is placed back on the load balancer.</p>
  
  <p>However, if the web.config file, like the rest of the web application's directory structure, is located on centralized storage, there is only one copy of the file, and individual servers could not be patched and warmed up anymore.</p>
  
  <p><strong>The Question</strong></p>
  
  <p>Is there a way to get an ASP.NET web application to take its marching orders from a source other than a file named Web.config?</p>
  
  <p>Ideally there would be one file per server, for example:</p>
  
  <ul>
  <li>default.aspx</li>
  <li>global.asax</li>
  <li>Web-ServerA.config</li>
  <li>Web-ServerB.config</li>
  <li>...</li>
  <li>Web-ServerN.config</li>
  </ul>
  
  <p>Where is the name "web.config" defined anyway?  Is there a registry setting that could be set on a per-server basis?  Is there an entry that could be made in the machine.config or the global web.config to specify what file to use?</p>
  
  <p><strong>Things Out Of Scope</strong></p>
  
  <p>Just so I am clear, I am not asking how to have different AppSettings for debug, test, and live.  There are other topics that cover this, and all my web.configs will be identical most of the time, the only time I need them to be different is when an update is being performed.</p>
  
  <p>We aren't using the web.config for any appSettings information; this is for the really important stuff, like assembly references, httpHandler definitions, and other system.web settings that can not be databased.</p>
  
  <p><strong>Update</strong></p>
  
  <p>I tried searching the registry for Web.config, and found nothing except for applications that noted that I had recently edited web.config files, which I apparently do a lot.  No help there.</p>