In dotnet one can write
which gives two debugging tools. The first is the ability to set a break point on the catch line.
Note how I haven’t written catch( Exception exc) but only catch( Exception). This makes us avoid a compiler warning because we don’t use the exc variable. Which brings us to trick number two in Visual studio: Since we don’t have a variable with the exception instead write $exception in the immediate window or the quickwatch window. $exception brings forward the [hidden] exception reference.
Also note how there is no variable behind the throw statement. This makes the framework hide the catch/throw and leave the stack intact.
Update: In VisualStudio2010 it looks like it is enough to write exception in the quickwatch window.
In an earlier article (or here) I mentioned a time saver for web projects where I recommended attaching to the process instead of restarting every time.
Today I invested time in creating a macro for attaching to the Nunit process. It was easy.
- Instead of learning all commands just record a new macro (menu->tools->macro->record temporarymacro) and connect to the process of choice.
- Then open the macro explorer (menu->tools->menu->macro explorer) which opens a toolbox. There is a (new) module called RecordingModule. Open this.
A new IDE opens with something like:
Sub AttachToNUnitProcess() ' MsgBox("AttachToNUnitProcess.Start") Try Dim dbg2 As EnvDTE80.Debugger2 = DTE.Debugger Dim trans As EnvDTE80.Transport = dbg2.Transports.Item("Default") Dim dbgeng(1) As EnvDTE80.Engine dbgeng(0) = trans.Engines.Item("Managed") ' Can be "Native". Dim proc2 As EnvDTE80.Process2 = dbg2.GetProcesses(trans, "MDG-VILTERSTEN").Item("nunit.exe") proc2.Attach2(dbgeng) Catch ex As System.Exception MsgBox(ex.Message) End Try ' MsgBox("AttachToNUnitProcess.Slut") End Sub
- Testrun your macro in Visualstudio just to make sure it runs properly.
- In the macro editor, create a new Module and copy the code you just created. Rename module and method. Save.
- Back in Visualstudio, Macro explorer, your new module should be visible. ”Should” – one might have to restart Visualstudio or the toolbox or something. It should be runnable directly from the Macro explorer toolbox.
- Create a new menu (menu->tools->customize …) and attach your macro. You find it under “Categories/Macros”, just drag it to your new menu or the menu bar.
Now attaching to a process is just a click or keystroke away.
Some more info is found here: http://msdn.microsoft.com/en-us/library/hdf2d1z8(VS.80).aspx.
Update: I debugged a web app for a while yesterday and Wow! – what a difference between 3 clicks and 1 click, or 3 keystrokes and 1 keystroke. Besides being simpler it also connected faster when the GUI didn’t have to render and didn’t have to wait for me. Why haven’t I done this years ago? What else is there I should have done years ago?
Update: I created a new menu and items for every macro I use. So Fast to use!
There is something that bothers me though. Some menus dissappear after I restart VSNet, I don’t know why.
The macros are easy to start also without having created a menu for them. Just alt-F8 and then arrow keys to find the right macro and start it with return.
Update: If I only use 1 macro I can use “run last macro” with shift-ctrl-P. I am using it right now because I am too lazy to create a new menu and stuff.
When debugging aspnet solutions a lot of time is wasted on restarting the debugged application. A real time saver is to connect to the process to avoid restarting.
This is done like so:
- When a new bug is found don’t stop the web browser, instead detach from the process (menu->detach->detach all).
- Update the code to correct the bug.
- Set a breakpoint.
- Connect (menu->attach to process->[find the process, it is called something like iis or aspnet]->attach) to the process.
- Reload the web browser.
There are some caveats. Like when using Webform the viewstate is tightly connected to the controls on the form so it is not always possible to connect.
But for the most times this is a great time saver.
When you have done this a couple of times even this takes long time. So fire up the macro recorder and do the recipe above. Then run the temporary macro. Running the macro is way faster than doing it manually. I guess it is all the GUI stuff that takes time.
Or store the macro in VS and create a button and/or a shortcut.
Update: use shift-ctrl-P to run last macro. Nice if one is too lazy to create a menu.