Breakpoints Not Hit Visual Studio 2005 on Vista

This one had me ready to gouge out my eyeballs, perform virtual self-immolation (Google the Dilbert strip if you can), or along with Captain Black of Catch-22, eat my liver.

Recreating Gouge Conditions
I created a toy website in Visual Studio 2005 on Vista, the breakpoints were hit ONCE but never again.

The reason, quite simply, is that on Vista you need to expressly Run Visual Studio as Administrator if you want your breakpoints hit. i.e. go to the Program Launch button in Vista, find Visual Studio 2005 and right-click ‘Run as Administrator’ on the context menu. Infuriatingly simple.

For this I humbly thank Vinblad from this Microsoft Visual Studio Debugger Forum thread who got the info from the blog of the intruigingly named Stephen Quattlebaum.

Stephen explains it:

Visual Studio 2005 starts IE by default when you debug an ASP.net project and (here’s the kicker) stops the debugger automatically when the IE process that it started shuts down.

The issue is that, due to protected mode in Vista, IE likes to restart itself immediately after it is started. As a normal user, you never notice, but it makes debugging IE in Vista hard b/c the process that you started dies right away, and a different, unrelated process starts up. The upshot is that just hitting F5 to start debugging in Visual Studio fails b/c the debugger starts up…and then immediately shuts down, b/c the process it was debugging died right away.

To always allow Visual Studio 2005 to Run As Administrator Browse to your install dir (C:\Program Files\Microsoft Visual Studio 8\Common7\IDE) and open the properties for devenv.exe. Switch to the compatibility tab and select “Run this program as an administrator”. Thanks to Eric Appel’s Digital Life

More
Here’s some more reasons why your breakpoints are not being hit:

1) You have deployment retail=true in machine.config (a Best Practice!)

2) You have selected a Production build as opposed to a Debug build from the ConfigurationManager and hence no debug symbols were generated.

3) You have been mucking around with stuff you don’t understand.

Don’t say you haven’t been warned.

Breakpoints Never Hit But Symbols Appear To Be Loaded

I was mucking around practising Javascript on a toy website I had made (using Web Site Project in VS 2005) and started up the VS debugger. To my deep consternation, none of my breakpoints were getting hit even though the breakpoint was set property and there was no warning about ’symbols not loaded’.

The reason for this turned out to be that I had inadvertently published my WebSite. A published website does not generate pdb symbols on build and hence cannot be debugged.

(NB: I only admit this publicly to save you the same embarrasment – so stop laughing and send money )

How Can I Tell If My WebSite is Published ?
It will have a PrecompiledApp.config associated with it. You will also find the Project folder for your site your site find has a sub-folder called PrecompiledWeb which contains an ‘appname’  folder which itself contains PrecompliedApp.config. e.g. Let’s say your Web Project is called “DogFood”. Your precompiled web site will have the following folder structure under ‘Visual Studio 2005′

• Visual Studio 2005/Projects/DogFood
• Visual Studio 2005/Projects/DogFood/PrecompiledWeb/DogFood

                PrecompiledApp.config
 

Related Posts
This post, “Why The Debugger Will Not Hit Your Breakpoints” on MSDN Blogs caused the necessary neurons to fire.

Keep Out Of The Reach Of Children
How did the web site accidently get published ? Well…err… it appears that SOME MANIAC COMPLETELY UNBEKNOWNST TO ME right-clicked on the web site project in Solution Explorer and selected ‘Publish Web Site’. Simple, quick and deadly. It should have a skull and crossbones icon on it, or be marked ‘don’t click under any circumstances’ or something…

How To Unpublish Your Web Site
I don’t think you can. But you can apparaently force a published Web Site to build with debug symbols using aspnet_compiler -d from a Visual Studio command prompt. See the post cited above for details.