Debugging through code

For really advanced users, the .NET class library opens up some of the interesting debugger APIs that you can invoke from your source code to call a debugger manually.

From the very beginning of a program, there is a DEBUG preprocessor variable, which determines whether the project was built in debug mode.

You can write the code in the following way:

#IF DEBUG
/// The code runs only in debug mode
#ENDIF

The preprocessor directives are actually evaluated during compile time. This means that the code inside IF DEBUG will only be compiled in the assembly when the project is built in debug mode.

There are other options such as Debug.Assert, Debug.Fail, and Debug.Print. All of these only work during debug mode. In release mode, these APIs won't be compiled.

You can also call the debugger attached to the process if there is any such process available, using the Debugger.Break()  method, which will break in the debugger at the current line. You can check the debugger. IsAttached is used to find out whether the debugger is attached to the current process.

When you start debugging your code, VS launches the actual process as well as one in .vshost in its filename. VS enhances the experience of debugging by enabling Partial Trust's debugging and improving the F5 experience by using the .vshost file. These files work in the background to attach the actual process with a predefined app domain for debugging to make a flawless debugging experience.

.vshost files are solely used by the IDE and shouldn't be shipped in an actual project.

VS needs Terminal Services to run these debuggers as it communicates with the process even when it is in the same machine. It does this by using a Terminal Service to maintain a seamless experience with both normal and remote debugging of a process.