Visual Studio 2010 - Debug T4 Templates

In the previous post we discussed about debugging T4 templates in Visual Studio based on the new option provided. This allows debugging T4 templates in the same Visual Studio Editor instance. As a matter of fact the options are new but we could still debug T4 templates by attaching external debugger.

Let's update the same project as we created in Visual Studio 2010. You can download the project and open it in Visual Studio 2010. In order to add an external debugger, we need to launch the debugger from the template code as follows:

In addition to launch external debugger we have also set debug attribute for template directive as true. Basically Visual Studio creates a temporary class to generate the text by the template. This template class is created on the fly. Setting the attribute as true would add it to a temporary directory. If there is a compilation error the we can open the temporary file from the Errors List debug window. After updating the template code, we can simply run the custom tool by manually running it. Saving the template would also run the same tool:



This should launch another instance of Visual Studio Editor. Click Yes on the following dialog asking for permission to open a new instance.



The debugger breaks the code execution at the line where we launched the debugger. We can now use all the debugging support in visual studio in order to step through the code.



We can also use other debug windows including Locals and Call stack windows in order to see the values of variables and call stack within the template code. It seems Autos window was broken even in Visual Studio 2010.

Tips & Tricks - Debugging Using Break Points

In the previous post, we discussed about using data tips for improved debugging experience. We also discussed how we can export them for a future visual studio session involving the same code base. I realized that there are various little features, related to break points are also there, which developers don't generally use while debugging. This post is to discuss how we can use break points efficiently for debugging our code. This is also intended to unveil and highlight any unknown useful feature involving break points.

Breakpoints are used for easily stepping through the code for improved debugging experience. Visual Studio attaches the code with a running process. It then allows breaking the code execution when a certain condition occurs. Breakpoints involve breaking the code in a non-exception related scenario although we can insert break points any where in the code we want.

Location and Data Breakpoints
Traditionally there has been two types of break points. They are Location and Data Breakpoints. The data break points are used for addresses in memory when the value at a certain address changes. For managed code, this feature is not available in Viusual Studio.



We can also see the similar disabled menu in Breakpoints window.



Location based break points are defined on a particular location. The break points can be set on a particular statement including statements within a lambda. There are two types of location based break points. One can be called as Normal break points which are just identified with the particular location. These break points are hit whenever the code corresponding the specified statement is executed. The other are advanced break points which are created when we assign certain details to the break point including hit count and condition which should be true or changed in order to break the execution of the code.

The feature also supports trace messages when a break point is hit. They are called Trace points. We can also select that the flow of execution is not broken when the trace message is written.

Inserting Breakpoint
There are different options in Visual Studio to insert break points. The first option is to directly insert it using the Breakpoints window. Just select Break at Function from New menu. The default key combination is Ctrl + D + N.



The same option is available in New Break Point option from Debug menu. The same key combination is applicable as it would show the same dialog for inserting Breakpoints.



Both these options would result in the following dialog box. You can specify the class and function name where you want to insert this break point. You can select the language too but selecting a different language wouldn't result in any error message and the Breakpoint would be added to the Breakpoints window but it wouldn't be inserted in the actual code. It does make sense not to insert the BreakPoint but it would have been better if there was any error message.



You can specify line number but any number other than 1 results in the following error message:



If there are more than one class and functions exist in multiple namespaces with the same name, an option would be provided to select the exact function. We can also select multiple places to insert the Breakpoints. Here we have added a new class in a different namespace with the same function name then following dialog is displayed to select the Breakpoints.



Toggling Breakpoints in Text Editor
When code file is being displayed in Text editor, you can place cursor at certain location and toggle the Breakpoint. Toggling the Breakpoint would insert the break point if it doesn't exist at the particular location, it would otherwise delete the specific Breakpoint. Here we have the cursor at the function, the following Debug menu should be available to insert the Breakpoint in the context menu if you right click at a certain location.



Alternatively we can also click on the side gutter, it would also perform the same toggling function for a Breakpoint.



When code is being displayed in the editor, the following option in the main Debug menu should also become enabled. The default key combination for toggling the Breakpoint is F9.



Inserting Breakpoins through Call Stack Window
The Breakpoints can also be inserted using Call Stack window. Just select the particular stack frame where you want to insert a Breakpoint. The Breakpoint would be inserted where the function is returned following the stack trace.



Insert Trace Point is used to insert a trace point at the selected location. They are used to write trace point. We will be discussing about them further in this post under When Hit section.

Breakpoints Window
Breakpoints window is a tool window providing the list of all Breakpoints in the solution. In the following image, you can see that it is listing the Breakpoints in one of our sample application.



The window can be displayed using the Debug Menu item by following through Debug Windows. The default keyboard shortcut key is Ctrl + D + B. In the below image you are just seeing the windows available when the break point is not being hit and the program is not in Break mode, otherwise, you should see a list of Debug windows available here.



Grouping Break Points
Breakpoints can also be labeled. These labels can then be used to sort and search through the Breakpoints. More than one Breakpoint can be assigned with the same label which can be used for grouping them. A Breakpoint can also be individually labeled. We can select these Breakpoints in Breakpoints window and select Edit Label from the context menu.

<

It allows us to select from among the list of labels created earlier. We can also create a new label and assign to the Breakpoint.



These labels are displayed in the Labels column in Breakpoints debug window.



Breakpoints can also be assigned with multiple labels. In this case all of these Breakpoints would be displayed in a comma separated fashion. The following Breakpoint is assigned to a line in the code. The code is assigned with two Labels. They are shown as follows:



These labels can now be used for search. We can disable all the Breakpoints in the code and search for the Breakpoints with a certain label. The Breakpoints with the particular label can then be enabled. This should make the debugging experience a lot better by allowing us to focus in the code area we mean to debug. By default, all columns are used for searching in the Breakpoints window but you can also specify any list of columns the IDE should use to search the specified pattern.

Enable / Disable Group of Break Points
As discussed above, Breakpoints can be enabled or disabled any point we require. A disabled breakpoint is shown as an empty circle in the side gutter of the window and in Breakpoints window. This shows that the code execution would not be broken when the line involving the specified line is hit. After searching the Breakpoints of interest, we can enable / disable those Breakpoints using the following in Breakpoints window.



Alternatively we can enable / disable all Breakpoints in the solution. This can be achieved by removing any search criteria and enabling / disabling all of them by selecting the option discussed above. Alternatively, this option is also available in Debug menu.



Delete Break Points
The same search feature of Breakpoints window can be used to find the Breakpoints we expect to delete. We might need to delete all Breakpoints we inserted to determine the cause of a defect which we have fixed now. Just select all the Breakpoints and hit Delete button in Breakpoints window.



A Breakpoint can also be individually delete. Once deleted, the breakpoint is removed from the Breakpoints window and Breakpoints icon is also removed from the side bar of the code editor.



We can also remove all Breakpoints in the solution using the Delete All Breakpoints option available in main Debug menu.



Export Breakpoints
Visual Studio 2012 also supports exporting these Breakpoints. As a matter of fact, this options was introduced in Visual Studio 2010. We can search the list of Breakpoints in Breakpoints Debug window and export them. These Breakpoints are exported in an Xml format to a specified file. The file is saved by using Save File Dialog where user specifies the name of file including its path.



The Breakpoints can also be individually exported. Just right click a Breakpoint in Breakpoints Debug window and select Export.



As discussed above the Breakpoints are exported in Xml format. The following is an example of exported Breakpoints from one of our sample projects created in some previous post.

The exported Breakpoints can then be used for a future Debugging session by the same user. They can also be shared with some other developer in the same team improving team collaboration. Just selecting Import should allow you to specify a source Xml file with the Breakpoints.



Advanced Breakpoints
Visual Studio IDE also supports advanced Breakpoints. These are the Breakpoints with added specification. They include Breakpoints with Hit count or conditions details. We can also specify process and thread related specifications for the Breakpoint definition. This is specially useful when more than one startup projects are selected or the code is being debugged in multithreaded scenario. These are displayed with an additional + sign in the side bar in the code editor. The same sign is used to show them in Breakpoints window.

Break When Hit Count
The default Breakpoint breaks the execution of code as many times the line involving the Breakpoint is being executed. We can provide extra details including to break the execution of code after the code has been hit so many number of times or a multiple of a number.



The following is the default hit count selection i.e. Break always. We can obviously change it.



Here we have changed the Hit Count details so that execution should break flow only when the specified statement is being executed for the number of times specified, or greater than that.



As discussed above, since it is an advanced Breakpoint, it is displayed with a + sign inside a circle. The circle is filled for an enabled Breakpoint, otherwise, for a disabled Breakpoint, it is empty.



Updating the hit count details should update the Hit Count column in the Breakpoints window.



Breakpoint Filters
Breakpoint filters are provided to qualify a Breakpoint with details including machine, process or thread. The machine details would be useful remote debugging sessions. Process related information can be used to debug code involving more than one process specially under the case of multiple startup projects in Visual Studio IDE.



We can even create expressions by joining various little expressions. The dialog is also handy in helping to create the expressions by providing info of the place holder variables for process, thread or machine specific information.



Conditional Breakpoints
A Breakpoint can also be qualified with a simple condition. This specifies that the breakpoint should only break execution when a a certain is either true or it is changed compared to the last time when this was being executed. Please remember that this is still a location Breakpoint which would be hit when the specified line is being executed. This is not a Data Breakpoint.



These conditions are displayed in the Conditions column in Breakpoints window.



Writing Trace Messages
Visual Studio also supports writing trace messages when a Breakpoint is being hit. Just search the Breakpoints of interest, and select "When Hit" from the context menu, the following dialog should be displayed:



These traces include the variables under scope. In the above example we are adding the value of a userName in the trace message. They are added using curly brackets. Please notice Continue execution option. Checking this option converts the break point into a trace point. A trace point is displayed as a diamond icon.



The trace messages can be noticed in the Output window as follows:



This is actually an updated feature in Visual Studio 2012. In Visual Studio 2010, the same dialog includes option for adding a macro to the details. The macro would be executed when the break / trace point is hit.



Due to very limited use of the Macros by the development community, Visual Studio 2012 has removed the feature of macro. It is removed from all the places which referred to macros including breakpoints. Visual Studio 2010 had support of Macro definitions. The option was available under Tools menu.



Breakpoints Not being hit
Break points should appear unfilled with borders on the side gutter display. Mostly it is just because the assembly couldn't be loaded to cause the break point to hit. Many a times, the assembly is just referencing a different version of .net framework including the following:

1. The target framework of application is target a client profile while the assembly is referencing the full .net framework.
2. The assembly has been built using X86 configuration, being loaded in a 64 - bit application.

In order to determine the list of assemblies loaded while debugging, Debugger modules window can be used in Visual Studio. SysInternal's Process Explorer can also be used for the same purpose. Fusion log viewer can be used to determine binding failures for assemblies.

Download ad PDF

Debugging using Break Points

Visual Studio Futures: Devlab's Debugger Canvas

If Software Development is an art then we (developers) should be called artists. An artist needs canvas to bring life into lines and colors. Debugger Canvas is a Visual Studio Extension to help debugging by providing a code bubble canvas where each bubble represent a portion of the call hierarchy. It is a Dev Lab's Power Tool developed which is now available as a Visual Studio Extension. In order to develop this, Microsoft's Code Canvas and Brown University's Code Bubble team joined hands. They worked in collaboration with Visual Studio team to come up with this amazing debugging experience. Currently, the only option to look at the call hierarchy is to look at the Call Stack Window. This can become really difficult for multithreaded and parallel code.



Code Canvas is a Microsoft Research Project. This project is about developing an multi-layered and infinitely zoomable surface for software development. You can get further information about this from their main page.

Brown University's main page for Code Bubble's team can be found here. It is a front-end to Eclipse. The code is available on SourceForge.net and can be downloaded. The idea of code bubble is coding for working sets. They are functions, documentations, notes and any other information that a developer need to implement a use case. This might be introduction of a new feature of fixing a defect in code. It works by displaying the editable functions in the form of bubbles on the view. These bubbles are fully editable and grouped in working sets. These bubbles are backed by code files and can be moved across the working sets. These working sets are displayed in a large bubble area. Kael has discussed about Code Bubble, Code Canvas and Debugger Canvas and their differences:

http://blogs.msdn.com/b/kaelr/archive/2012/03/10/code-canvas-vs-code-bubbles-vs-debugger-canvas.aspx

* Code Bubbles is a trademark of Brown University.

Visual Studio Extension for Debugger Canvas
Debugger Canvas is available as a visual studio extension in Visual Studio Gallery. It is made available by as a DEVLABS project provided from Debugger Canvas Team. The extension was last updated on 02/15/2013 and it is available as version 1.1. The limitation is that it is not available for Visual Studio 2012. The extension is only supported for Visual Studio 2010. The documentation suggests that it would only work for Ultimate Edition.



The extension can be downloaded from the following link:

http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-4adf-bfef-83bd428a0acb

The extension has a dependency on another extension VS Fragments.



The documentation of the extension suggests that the extension would work only with Visual Studio 2010 Ultimate Edition. I tried installing it on Visual Studio 2010 Premium RTM and it installed successfully. The documentation also suggests that some features wouldn't be available on RTM version and SP1 is required. I noticed that there is no intellisence during debugging in code fragments / bubbles in canvas window. Since there is no intellitrace available for Premium edition, I couldn't test the code bubble tree created by dropping an intellitrace event on the canvas.

What is Debugger Canvas?
Debugger canvas adds features in Visual Studio 2010 to improve debugging experience. The whole idea is to provide a single canvas. This is a pan and zoom surface i.e. it can be zoomed in and out, plus we can pan the window by dragging it from any point in the surface.

The canvas appears as a tabbed window. It shows the code portions in the form of bubbles / fragments. The bubbles support stepping through the code like the already existing debugging feature in Visual Studio. The only difference is that each call is shown as a bubble with an arrow directing from caller to the callee code. This is a debugging experience which is completely temporary i.e. it can not be persisted as is.



There are also other features in the surface. The greatest of all is the enhanced search. We can search the code for any references and it would show all the patterns available in the code bubbles in the surface. just right click anywhere in the canvas surface, you should see the following options:



The online MSDN forum is about discussion and announcement about the tool [ http://social.msdn.microsoft.com/Forums/en-US/debuggercanvas/threads]. Like other MSDN forums, you can ask questions which is then discussed by other members of the community.



Debugger Canvas Menu
Installing the extension would make the necessary features in Visual Studio. This includes the additional Debugger menu. Notice that I can run it with Resharper. The documentation suggests that they are not compatible.



Please notice the options for saving the canvas to the XPS document. You can also do this by one of the context menu options available in the canvas.

LifeTime of Debugger Canvas
As discussed above, debugger canvas is a pan and zoom surface helping debugging of complex code. Code fragments / bubble appear on the canvas as they are called. The lifetime of a Debugger Canvas is for a single debugging session. As we have discussed before a debugger canvas is represented as a single tabbed window, this window can be used for the next debugging session if this is still opened. It uses the most recent canvas window if more than one are opened.

Intellitrace & Debugger Canvas
Intellitrace is another debugging tool to help debugging experience. It is available with Ultimate Edition of Visual Studio. The traces generated through Intellitrace can be used by Debugger Canvas to see the call hierarchy using code bubbles with all the parameters. This call hierarchy can always be exported into XPS format to share it with the concerned parties.

Debugger Canvas Settings
There are some options in Debugger Canvas which are configurable. The configuration settings are available under [Debugging -> Debugger Canvas] in Tools -> Options dialog. The same dialog is available under Debugger -> Options and Settings.



Starting Debugger Canvas
A user can select how he wants to start the Debugger Canvas. This can be controlled based on the following settings:



When this option is checked, any time user starts a debugging session, Debugger Canvas is used. The first break point hit creates the bubble. These bubbles are added / reused as we keep stepping into the functions. This option is based on code analysis functionality in Visual Studio which transforms code into generalized graph based model. The same functionality is used by Architecture Explorer, available in Visual Studio Ultimate Edition. This actually requires some extra work when debugger canvas is used for debugging, compared to general file based debugging experience in Visual Studio. This requires scan of the whole solution and generating a graph based model. So selecting this as default option, it might be slower to start the debugging session. Un-checking this would use the general file based session in Visual Studio. You can later invoke the debugger canvas using the following toolbar added with the installation of the extension. This is available when you start a debugging session.



The option is disabled when we get out of the debugging session. I have noticed that if you have this option unchecked and start a debugging session and just have the debugger canvas window opened in a tab, it would start using the canvas. I think this is just to use canvas as it is definitely a better debugging experience. It might seem like a defect for other developers as they might not expect this.

Debugging recursive code
It has been traditionally very difficult to debug recursive code because of complex call hierarchy to the same methods. Debugger Canvas becomes specially useful for debugging recursive code. This allows to disable the reuse of bubbles for the same content. This can be used to have a new bubble for each call with the exact call hierarchy. It even provides the values of local members for each bubble in the hierarchy. What could be better than this?



Just to show the benefit for this visually, let's uncheck the above setting and start debugging using debugger canvas. Let's consider the example of fibnacci series. The following is a recursive implementation of Fibnacci series. You can see that each call is represented in the canvas. You can also appreciate how local variables are also available in the call hierarchy.



Actually this setting came from neither Code Canvas nor Code Bubbles individually. Code Bubbles has a non-historical design where it doesn't reuse any bubble and every time a new bubble is created even if the users steps into the same code. This has the advantage of simplicity and predictability. On the other hand, Code Canvas works in historical mode and it reuses the fragment if the same code is hit again. This keeps the canvas real estate occupied by less number of fragments. For Debugger Canvas, user is given option to decide what mode he wants to select and the debugging experience is updated based on this selection i.e. Historical Vs Non-Historical debugging using bubbles.

If your call hierarchy are not like that then reusing the bubbles would definitely simplify the view.

Local Variables Snapshots:
If a code bubble is being used multiple times then we can just take a snapshot of local variables. These snapshots are taken with time stamps. These values can then be used to compare with the local values whenever the same bubble is used again. In the following example we have taken a snapshot of a recursive method and compare the values from the values when we took these snapshots.



Canvas Debugging Channels
As we discussed above, the canvas is displayed as a tab window. The bubbles for each new session are provided in the form of horizontal channels. The canvas keeps the channels from previous debugging channel which might help in comparing the current session from any previous one. We can easily determine if the bubble is from a previous session as the border turns blue as we select it. For a bubble from the current session, the border becomes yellow. We can pan and zoom to just focus on the current channel. It is easy to navigate between different areas in the canvas by using the Visual Selection Pane on the top. It is based on an expander. It provides the display of the pane using a Visual Brush.



Call Hierarchy
The canvas supports removing the bubbles from the call hierarchy. How the display would look like if we remove a bubble from the middle of the hierarchy. In the image below, I have the channels from two debugging session. For the current session, I have removed a bubble from the middle. Initially, it appeared that there is no relationship between the ancestral code block but when I dragged the child bubble a little on the canvas, it did create a dashed line showing an indirect caller - callee relationship.



Editing in Debugger Canvas
The canvas allows editing of code while debugging. Just put the cursor at the place in the code that you want to modify and just update the code. This can be configured though, which can be disabled.



When I tried this feature, I was thinking it would depend on the Edit and Continue feature but it doesn't, even when Edit & Continue is disabled.



Integration with Existing Debugging Tools
The debugger canvas seems to be completely integrated with the existing debugging tools in Visual Studio. In the following, the Call Stack and Threads toolbar window is displayed. As we double click an item in the call stack from either of these, it results in a bubble in the canvas. It also creates a call relationship by using arrows.



It is also integrated with other debugging tool windows including Autos, Locals and Immediate windows. Since we have the support of local members right on the canvas, I don't think anyone would use Locals and Autos when using a Debugger Canvas. But Immediate Window would definitely be very useful.



It is also integrated with Quick Watch Window.



Integration with Visual Studio 2012
The major road block is that it is not supported in Visual Studio 2012. It is understandable that this is a parallel development started somewhere in 2010 when Visual Studio 2012 wasn't even available. There should be an real effort to support Visual Studio 2012. I also think that this should be available in non-Ultimate editions of Visual Studio but since it is based on some features, including code analysis feature, which are only available in the ultimate edition, it seems obvious that it would be really difficult or impossible to provide it for other editions.

Research Paper on Debugger Canvas
This discusses the details about the design choices with Debugger Canvas. This also sheds some light on the initial community feedback of the tool. It mentions some of the motivations about the feature design choices. [ Kael Rowan, Robert DeLine, Andrew Bragdon, and Jens Jacobsen, Debugger Canvas: Industrial Experience with the Code Bubbles Paradigm, International Conference on Software Engineering, 2 June 2012]. You can get it from here:

http://research.microsoft.com/pubs/177124/p1064-213-deline.pdf

Channel 9 Video with Kael Rowan:
Kael has a very useful conversation about this on Channel 9.

Debugger Canvas