Hi
I am wondering is this normal when you add this into your web.config
<location path="." inheritInChildApplications="false"> </location>
The debugger should stop working. Like when I add this to my site and try to run in debug mode it won't activate any of my debug points nor will it lock up Visual studios 2008. I can have it running and still make edits to my C# code.
I take the line away and I get the debug mode back and it locks up VS2008.
UPDATE #3 After doing a lot of research into this attribute I have brought everything together in one article here:
Original Post
This does appear to be normal behaviour. I have experienced the same thing and it stopped me in my tracks for a while trying to figure out what I had done wrong.
If you have the location tag as above then when you press the play button to start debugging it will compile, launch the site and then immediately close the debug session. Your website will load up and you will be able to use it as normal but if you look at it in visual studio you will see the debug play button is available and the app is not considered to be currently being debugged.
Commenting this out and repeating the debug process results in it immediately starting to debug correctly again.
I am in the situation now where I have to comment the tag out locally when I do work on a site with this in and then remember to uncomment it before I upload it again to the server.
Pretty annoying because I hate leaving things like this to the chance of me remembering.
Hopefully I will be able to automate this attribute when .net 4 comes out and we get our hands on the web.config transformation tools.
UPDATE While doing some research into this for an article I am writing it seems that this is a known bug:
The current work around is as suggested - comment out the <location> tag to debug.
UPDATE #2 While doing some research into this problem I have found a scenario which can cause a server error. It doesn't solve your problem unfortunately but if you are using the <location> tag then you might run into this problem soon enough:
The article describes a technique which basically creates multiple versions of tags in the web.config inside and outside of the <location> tag. In my article I create a second <system.webServer> tag and when I saw it worked I immediately thought of this thread. While it did let me create a second <system.web> and move the <compilation> tag outside of the <location> I then ran into further dependency problems which prevented me from successfully compiling.