CodeAttest
VSTS, Oslo, INETA, ASP.NET, Debugging .NET Applications, Tips and Tricks

March 04, 2006

Debugging and .vshost.exe

Using Visual Studio and its debugger gets easier and easier these days. It is an inevitable process and we can not stop it. That’s what people want. But this usability comes has its price.
Few months ago I wrote about the disadvantages of the integrated development web server in VS 2005. Today I had bad experience with another new feature of VS 2005.
I was debugging a nasty problem in WSE 3.0 and after two hours I finally got to a working solution. Suddenly my project stopped working at all with a strange exception on a place that was totally unrelated to the problem that I was diagnosing for hours.
After another half an hours wondering what is going on here, I decided to delete all complier generated files – just in case. At the time I did not know that VS 2005 creates a complementary file with extension .vshost.exe. It is a new feature that I was not aware of.
Basically the idea of the Hosting Process is the following. When you load your project, that’s right - load not run, a new process is created with extension .vshost.exe. This process improves the debugging performance, helps for debugging partial trust assemblies and allows you to write code in the Intermediate window even when you are not debugging. Honestly, things that either I do not use or do not care about.
My first reaction was – does not this change the behavior of the program when it is in the debugger? Does not this introduce the Heisenberg principle and thus messing up our debugging experience instead of improving it?
My memory freshens and a bulb light up.
During my debugging session I saw that the symbols did not load due to this: "Skipping loading symbols. Module is optimized and the debugger option ‘Just My Code’ is enabled". This is yet another new feature of VS 2005. It makes visible to the debugger only the code that you have written so you can not lose yourself in third party libraries. It seems that when I disabled this feature, the process .vshost.exe was not aware of this change and my application threw that strange exception.
The good news is that there is a way to restart the .vshost.exe process. I first through that via the extensibility features of VS I could restart that fellow process, but things are simpler enough. Just go to Build\Rebuild solution (Alt+B\R) and the process will be recreated. At least now in VS 2005 we know what exactly the difference between Build and Rebuild options is :)

# posted by Martin Kulov @ 9:51 PM




This page is powered by Blogger. Isn't yours?

 




Calendar Martin Kulov's Calendar   RSS Aggregate this blog

DevReach - The Premier Conference for Microsoft Technologies for SEE

Mobility Day 2008 Conference

DevReach - The Premier Conference for Microsoft Technologies in Bulgaria

International Association of Software Architects

SofiaDev .NET User Group

Microsoft Most Valuable Professional

View Martin Kulov's profile on LinkedIn

MSDN Event Bloggers




Recent posts




History




 
Copyright © 2004-2008 CodeAttest Ltd. All Rights Reserved.