Most of us have probably used or know of the System.Diagnostics.Debugger.Break(). For more information on Debugger.Break checkout this link http://msdn.microsoft.com/en-us/library/system.diagnostics.debugger.break.aspx
Online documentation states that if no debugger is already attached, user would be prompted to attach one to executing program when the break is hit. For some reason however, this didn’t work for us when our desired breakpoint was in an OnInstall() function of an installer class.
Further digging revealed that the comments decorating the Break() call differ a bit from the online documentation:
// Summary:
// Signals a breakpoint to an attached debugger.
//
// Exceptions:
// System.Security.SecurityException:
// The System.Security.Permissions.UIPermission is not set to break into the
// debugger.
[SecuritySafeCritical]
public static void Break();
Apparently, Break() only signals a breakpoint to an attached debugger as per the summary above.
In looking at other calls within the Debugger class, we found the Launch() function which is documented as following:
//
// Summary:
// Launches and attaches a debugger to the process.
//
// Returns:
// true if the startup is successful or if the debugger is already attached;
// otherwise, false.
//
// Exceptions:
// System.Security.SecurityException:
// The System.Security.Permissions.UIPermission is not set to start the debugger.
[SecuritySafeCritical]
public static bool Launch();
This call forces the launch of debugger selection prompt where we can select Visual Studio 2010 as our JIT debugger. Once selected code execution breaks allowing us to step through the code. The Deubbger.Launch() call worked perfectly when called inside our OnInstall() function and allowed us to conveniently debug installer code.