Ran into another fun little problem a few days ago. Working on my root Web site which is rather large and contains a huge number of sub-webs. The root site is very light in terms of ASP.NET functionality used - primarily stuff like cookie tracking and logging tasks, serving banners etc and a few utility applications. Most of the heavy lifting on the site and 'real' applications are managed in virtual directories that handle real processing.

So yesterday over the last few days I've been building a small utility form that hooks up to Html Help Builder and allows generating documentation online for demonstration. This page lives in a directory off the root Web site, but it's part of the Root Web application and so runs under the root site. At some point I needed to debug the code and so I start the debugger on this large Root web and...

Well it looks like the debugger is starting up, but in fact it's just starting and then immediately aborting. There's no error message, no output window message, but IIS or the internal Web Server simply fail to attach the debugger and so while the app runs just fine, there's no debugging.

My first thought was that this is caused because it's a root Web and the site is very large. There are over 10,000 files that are part of the root web and singnificantly more when counting the child virtuals that live underneath the root. Surprisingly VS 2008 SP1 deals with this sizably Web pretty well in terms of speed of bringing up the solution - size is apparently not the problem.

Alas, it turns out the problem has nothing to do with size, but rather that I have a <location> tag in my web.config that pretty much wraps the entire web.config to prevent the root web settings from trickling down into child Web sites. Specifically I don't want authentication and handlers/modules be required in child virtuals which otherwise would require every child web to either explicitly remove handlers and modules or add them to the virtual's bin folders which is shitty to say the least.

My workaround for this is to use a <location> tag

<?xml version="1.0"?>
<configuration>
  <location inheritInChildApplications="false">
    <system.web>
      <compilation debug="true">
        <assemblies>
          <add assembly="System.DirectoryServices, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />
        </assemblies>
      </compilation>

      <pages>
           <namespaces>
               <add namespace="Westwind.Tools"/>
               <add namespace="Westwind.Web.Controls"/>
               <add namespace="Westwind.Web.Banners"/>
            </namespaces>
      </pages>
      <trust level="Full"/>
      <authentication mode="Windows"/>
      <customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm">
                <error statusCode="403" redirect="NoAccess.htm"/>
                <error statusCode="404" redirect="FileNotFound.htm"/>
      </customErrors>
   </system.web>
   <system.webServer>
            <handlers>
        <add verb="GET"
               name="wwBanner"
               path="wwBanner.ashx"
               type="Westwind.Web.Banners.BannerHandler, Westwind.Web.Controls" />
        </handlers>
            <validation validateIntegratedModeConfiguration="false"/>
    </system.webServer>
   </location>
</configuration>

The inheritInChildApplications="false" is quite useful and prevents any of the settings in the configuration to riple down to child virtuals. This attribute can be applied to many section headers, but if you want a whole slew of tags not to propagate down the <location> tag is a great place to apply this attribute because it effectively encapsulates all data beneath it.

Unfortunately it looks like this configuration is also the cause that Visual Studio fails to start the debug. Removing the <location> block allows me to debug just fine.

Specifically it's the compilation section that must be outside of the <location> block. If I move the <compilation> section outside of the location block I can also start debugging. The following also works:

<?xml version="1.0"?>
<configuration>

  <system.web>
    <compilation debug="true">
      <assemblies>
        <add assembly="System.DirectoryServices, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />
      </assemblies>
    </compilation>
  </system.web>
  
  <location inheritInChildApplications="false">
...

Depending on what you have inside the <assemblies> section of the compilation tag this may or may not be acceptable as referenced assemblies here will get loaded when the app starts and so can slow down load times for your child virtual AppDomains.

I suppose it's not terrible problem because this is likely only going to be a problem only in debugging scenarios. It's not a big deal, but it's yet another mysterious cause for when debugging doesn't work, but hopefully this will help out those of you searching for a solution to a similar problem.