Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
Markdown Monster - The Markdown Editor for Windows

Unable to debug Web Site with Top Level Location


:P
On this page:

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.

Posted in ASP.NET  

The Voices of Reason


 

Kamran Shahid
August 28, 2008

# re: Unable to debug Web Site with Top Level Location

Good One Rick

Guy Harwood
August 28, 2008

# re: Unable to debug Web Site with Top Level Location

Im actually debugging an app that works like this right now, based on your previous post about that location tag attribute. Its actually outside of the main app on my local machine because debugging didnt work - so this is good to know!

one thing i am finding is that authentication seems to be erratic on the live site since we used the 'inheritInChildApplications' attribute. People are having to re-login multiple times in a 5-10 minute session. Whether its related or not i cannot be sure. But its damn annoying and very difficult to track down.

Tim Cartwright
May 22, 2009

# re: Unable to debug Web Site with Top Level Location

AWESOME. This has been kicking my butt for days.

Tara at Technimedia
June 24, 2009

# re: Unable to debug Web Site with Top Level Location

Thank you, Rick. Re-arranging my web.config fixed it. It was a bang-your-head-on-the-desk problem and its was solved with your tip.

Geogie Varughese
October 23, 2009

# re: Unable to debug Web Site with Top Level Location

Your article just helped me solve the issue that I had with one of my vs2008 projects not being able to be debugged.
Thanks

rafael
December 03, 2009

# re: Unable to debug Web Site with Top Level Location

you are may hero today!
I've been dancing around this issue for hours.

thanks!

JKong
March 24, 2010

# re: Unable to debug Web Site with Top Level Location

you are the man Rick. Period.

Joe
June 24, 2010

# re: Unable to debug Web Site with Top Level Location


i added the location tag to my site to add a virtual folder and have not been able to debug the site the last few days. i did not relate this change some weeks ago to my current debug problem. I wished i had stumble across this post a few days ago and save myself some agony.

cheers...

Adil
May 07, 2012

# re: Unable to debug Web Site with Top Level Location

Thank you my friend. Have been scratching my head for a while. I am curious though - what made you realize that it was the compilation block that needed to be outside the location block?

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024