Habib Heydarian's Blog @ Microsoft

How to Count the Lines of Code (LOC) in your application using Visual Studio

habibh — Wed, 28 Oct 2009 01:30:46 GMT

I was talking to someone the other day and he asked me whether Visual Studio has a tool to count the lines of code in an application. It occurred to me that others might be interested in the answer so I decided to blog about it.

There is a tool called Code Metrics in Visual Studio 2008 and 2010 that among other things, counts the lines of code in a project. Using Code Metrics is very simple. In Solution Explorer, select the project that you want to know the LOC for, right-click and select "Calculate Code Metrics".

The screenshot below shows the Code Metrics window. One of the nice things about the Code Metrics window is that it shows you the lines of code per project, namespace, class or method.

Habib Heydarian.

Looking for questions or feedback on IntelliTrace

habibh — Tue, 27 Oct 2009 05:23:05 GMT

During the last few months, I've been blogging extensively about a new Visual Studio 2010 feature called IntelliTrace (formerly known as the "Historical Debugger"). We are very excited about IntelliTrace and think that it's going to change how people debug their applications.

Since IntelliTrace is a brand new feature, we are eager to hear from developers about what they think about it. So, here is my offer: If you have any questions or feedback (both positive and negative) about IntelliTrace, send me your feedback via this blog and I will reply with an answer within 24 hours. Regardless of weather you've used IntelliTrace extensively and have an "advanced" questions, or you've never used it before and just want to learn about it, I'll be happy to answer any questions related to IntelliTrace.

Thanks in advance.

Habib Heydarian.

Using IntelliTrace to view the return value of a VB or C# method

habibh — Sat, 24 Oct 2009 04:30:00 GMT

A few months ago, I blogged about how to view the return value of a C# or VB method in the Visual Studio debugger. As I explained in that blog post, the debugger does not support viewing the return value of a .NET method, so you have to apply a workaround or two.

Being able to see the return value of a method comes in particularly handy when you have methods that take other methods as their parameters, e.g. F(A(x), B(y)), where A() and B() are methods themselves. For example, in the code example below, how can you see the value that is returned by c.CalculateArea(radius)?

IntelliTrace in Visual Studio 2010 makes it easy to view the return value of a method.

The first step is to change the default IntelliTrace options to record "events and call information", as shown below.

After enabling the above option, IntelliTrace will record the return value and parameters of all methods in the running application. Now, whenever you stop in the debugger, the IntelliTrace NavBar is displayed in the editor margin. To see the return value of a method, click the "Go to Previous Event" button (Ctrl+Shift+F11) to step back to the method that you want to see the value for, shown below.

After clicking the button, the debugger will display the method that you stepped back to in the Autos window, as shown in the following screenshot.

Expanding the method in the Autos window will display the return value. The debugger displays the name of the return value as [Return Value].

Habib Heydarian.

IntelliTrace is not available. Why?

habibh — Thu, 22 Oct 2009 16:53:59 GMT

When using IntelliTrace, you might run across the following error message in the IntelliTrace window:

IntelliTrace is not available. See the Debugger Output window or the Windows Application Events Log.

Below is a list of reasons why you might see the above error message when trying to use IntelliTrace.

1) In Visual Studio 2010, IntelliTrace does not support debugging a 64-bit process inside Visual Studio. You can workaround this limitation by changing the project configuration for your project to 32-bit. See this article for more details.

2) IntelliTrace is not available if you have attached to the application that you are debugging. The only workaround is to start the application under the debugger.

3) IntelliTrace is not supported for native C++ applications. We hope to fix this limitation in the future.

4) IntelliTrace does not support SQL CLR projects

If you have any feedback or are seeing the above error messages in other scenarios, feel free to send me feedback.

Habib Heydarian.

The future of debugging is here! Visual Studio 2010 now supports stepping back in the debugger.

habibh — Thu, 22 Oct 2009 05:05:20 GMT

In my previous post Getting Started with Visual Studio 2010 IntelliTrace: Hello IntelliTrace!, I described how to use the new IntelliTrace feature in Visual Studio 2010 to debug an application. But there's more to IntelliTrace. IntelliTrace also allows you step back in the debugger! However, the step back functionality isn't enabled by default. You can enable this feature via Tools->Options->IntelliTrace. On the IntelliTrace Options dialog, select the IntelliTrace events and call information option. This is shown in the dialog below.

After selecting the option, you can now use the debugger step back through the code. In the following screenshot, you can see a before and after screenshot. On the left hand side (screen 1), the Step Back button is highlighted. The right hand side (screen 2) shows what happens after I've clicked the Step Back button, i.e. the debugger has stepped back into the calling function, Main().

We are very excited about IntelliTrace and we think it's going to change developers' lives. If you have any questions or feedback about IntelliTrace, feel free to drop me a line.

Habib Heydarian.

Getting Started with Visual Studio 2010 IntelliTrace: Hello IntelliTrace!

habibh — Wed, 21 Oct 2009 02:41:20 GMT

One of the most talked about features in Visual Studio 2010 Beta 2 is IntelliTrace. In a nutshell, IntelliTrace allows a developer to record the application execution and play it back. Using IntelliTrace, a developer can do some cool things like step back in the debugger.

In this blog post, I'll do a "Hello World!" version of IntelliTrace to help you get started with this feature. We'll start with a vanilla Windows Form project and use it to explore various capabilities of IntelliTrace.

To start with, create a brand new Windows Forms project using either VB or C#. Then, drag and drop a button on the form, as shown below.

Double-click on the button and add the following line to the click event handler.

Debug.WriteLine("Hello IntelliTrace!")

Press F5 to run the application and then click on the "Hello IntelliTrace!" button. On the right-hand of the screen, you should see a new window called the IntelliTrace window, as shown below. Click on the "Break All" link in the IntelliTrace window.

After clicking the "Break All" button, the IntelliTrace window displays a number of very useful "events", as shown below. IntelliTrace records what happened in your application in chronological order. So, reading down the IntelliTrace window, you can see that the following things happened:

The application started under the debugger
The user clicked on a button with the label "Hello IntelliTrace!"
The application output some trace information using Debug.WriteLine()
The application paused in the debugger

What IntelliTrace is doing is keeping a diary or journal of the application as it was executing so that you can read through what happened. But what really makes the experience that much more compelling is that you can click on an event in the IntelliTrace window and navigate to the source code that caused that event, shown here.

In the next blog, I'll describe how you can customize IntelliTrace to collect additional events such as opening a file or reading from Windows registry keys.

Habib Heydarian.

Visual Studio 2010 Beta 2: The Historical Debugger is now IntelliTrace!

habibh — Mon, 19 Oct 2009 16:01:00 GMT

Over the last few months, I've blogged a fair amount about a new feature in Visual Studio 2010 called the Historical Debugger. With the announcement of Visual Studio 2010 Beta 2 also comes a name change for the Historical Debugger. It is now called IntelliTrace™.

Background: We literally spent over two years agonizing over the name for the Historical Debugger. In fact, the team made a list of over 100 candidate names. After much debate, some tears and lots of back and forth, we settled on the name IntelliTrace. So far, many people have told us that they much prefer the name IntelliTrace over Historical Debugger.

Despite the name change, much of the functionality of IntelliTrace remains the same as I had described before. For a refresher, here are a set of blogs that will get you started on IntelliTrace.

In the coming weeks and months, I'll be writing a lot about IntelliTrace and how you can use it to make debugging much more productive.

Habib Heydarian.

How to edit code when debugging a 64-bit application

habibh — Tue, 13 Oct 2009 05:19:55 GMT

One of the most popular features in the Visual Studio debugger is the ability to edit code during a debug session and have the changes apply without having to stop the debugger, recompile the application and then run the application to verify the changes. This feature is affectionately known as "Edit and Continue" or "E&C" for short.

Unfortunately, Edit and Continue isn't supported on 64-bit. In fact, if you try to use Edit & Continue when debugging a 64-bit application, you get the following error message: "Changes to 64-bit applications are not allowed", as shown below.

Many users may not be aware that by default, when you create a C# or VB project in Visual Studio 2008, the "Platform" for the project is set to "Any CPU". This means that if you run your application on a 32-bit operating system, your application will run as a 32-bit process and similarly, if you run your application on a 64-bit operating system, the application will be 64-bit. The consequence of "Any CPU" is that when you try to debug your application on a 64-bit operating system, you won't be able to use the Edit and Continue feature.

However, there is a workaround. During development, you can set the Platform for your project to 32-bit which means that your application will run as a 32-bit process even on a 64-bit operating system. This is known as WOW64 or "Windows On Windows" which basically means that you can run a 32-bit application on a 64-bit operating system.

So, how do you set the Platform for your project to 32-bit? Well, you need to create a 32-bit platform using the Visual Studio Configuration Manager. Here is a short walkthrough.

First, open the "Configuration Manager" dialog from Build –> Configuration Manager. The Configuration Manager dialog is shown below.

On the Configuration Manager dialog, select "New..." from the "Active solution platform" dropdown, as shown here.

On the "New Solution Platform" dialog, select "x86" and press the OK button.

That's it! Your project is now compiled as a 32-bit application and therefore, it also runs as a 32-bit process.

An important note to remember is that if you are planning to deploy your application to a 64-bit machine and you want the application to run as a 64-bit process, don't forget to set the project platform back to "Any CPU" and compile the project.

Habib Heydarian.

RUNTIME turns 100,000!

habibh — Tue, 29 Sep 2009 07:53:55 GMT

Today represents a huge personal milestone. My car reached a 100,000 miles! There is nothing unique or special about my car except the license plate and the Visual Studio logo on the hood. Most of my friends refer to the car as RUNTIME (for obvious reasons).

I purchased it when I first joined Microsoft from my first manager and have had it since then. It's a great little utility truck.

Habib Heydarian.

Debugging a COM object (Runtime Callable Wrapper) with Visual Studio 2010

habibh — Tue, 22 Sep 2009 10:31:00 GMT

If you have written managed code that uses a COM object, then you are probably familiar with System.__ComObject. When a COM object lacks a Runtime Callable Wrapper (RCW), the CLR provides a generic RCW which is an instance of the type "System.__ComObject". Unfortunately, one of the downsides to System.__ComObject is that the Visual Studio 2008 debugger cannot display its members.

Let's look at an example. When I was writing this blog post, I wrote a tiny console application that would speak the word "Hello" using the Microsoft Speech Object Library (SpeechLib) which is a COM API.

        1: using SpeechLib;

       2:  

       3: class Sample

       4: {

       5:     static void Main()

       6:     {

       7:         SpVoice spVoice = new SpVoice();

       8:         spVoice.Speak("Hello", SpeechVoiceSpeakFlags.SVSFDefault);

       9:     }

      10: }

Unfortunately, as soon as I ran the application, the application threw a COMException with the HRESULT 0x8004503A, as shown below.

Since I didn't know what the problem was, I added the variable "spVoice" to the Watch window to have a closer look. However, the debugger couldn't show me anything since I didn't have a RCW for SpeechLib and hence the CLR had generated a generic one at runtime. So, I'm somewhat stuck at this point.

Luckily, in Visual Studio 2010, there is now a "Dynamic View" that displays all the members of a COM object of type System.__ComObject, as shown below.

Expanding the "Dynamic View" node displays the members of spVoice. As can be seen from the screenshot below, the reason for the exception was because the audio service on my computer wasn't running. This makes sense since I was running this demo on the Hyper-V virtual machine.

Habib Heydarian.

Coverage of the Visual Studio 2010 Historical Debugger

habibh — Mon, 21 Sep 2009 10:04:00 GMT

During the last couple of months, I've covered the Historical Debugger extensively. If you are interested in learning more about this new feature in Visual Studio 2010, the following blog entries should help you get started.

Habib Heydarian.

An in depth look at the Historical Debugger in Visual Studio 2010 (Part VI)

habibh — Sat, 19 Sep 2009 06:48:38 GMT

In previous blogs, I have covered the Historical Debugger extensively and talked about many of the scenarios. In this post, I'll walk through another scenario where the Historical Debugger is very useful which is Load Testing. When loading testing an application, you can have the Historical Debugger collect information during the run and if one or more of the tests fail, you can use the Historical Debugger log file to debug the test failure(s).

Let's walk through an example. For this walkthrough, I have a Load Test which contains a single Web Test. The application under test is the BeerHouse sample application.

The first step in setting up the Historical Debugger for collecting data during load testing is to enable the "Diagnostic Tracing" option in the Test Settings, as shown below.

Once you've enabled the Historical Debugger, the next step is to run the Load Test. After the Load Test is complete, you should see the test result details which also includes the number of errors, shown below.

While the Load Test was executing, the Historical Debugger was recording the execution history. The following screenshot shows the Historical Debugger log file (QTAgent32_000013d0_090918_204309.tdlog).

Double-clicking the log file opens the Historical Debugger Summary page, shown below. Using the summary page, you can investigate the root cause of the test failure.

Habib Heydarian.

Class Breakpoint: How to set a breakpoint on a C++ class in the Visual Studio Debugger

habibh — Thu, 10 Sep 2009 21:34:00 GMT

When debugging an application, there are times when you want the debugger to stop whenever any of the functions in a particular class are called. An example of this may be when you are trying to find out which object is calling your class. Of course, you could manually set a breakpoint on every function in your class but that is both tedious and time consuming, not to mention error prone (what if you miss one of the functions?)

What you really want is a "class breakpoint", that is, a breakpoint on an entire class and all its functions, operators, constructors, etc. In Visual Studio, you can set a "class breakpoint" using a function breakpoint. Specifically, when setting a function breakpoint, instead of specifying a function name, you can specify the name of the class followed by the '*' wildcard character. The '*' wildcard indicates to the debugger to break on "anything" that is called within the class.

Let's go through an example. In the following class declaration, I want to set a breakpoint on all methods in the Stack class.

class Stack
{
private:
    list<int> m_list;
public:
    void push(int i);
    int pop();
    int depth() const;
    bool empty() const;
};

To do that, I can bring up the "New Breakpoint" dialog by pressing CTRL+B as shown below and type in Stack::* for the function name, as shown below.

After setting the breakpoint, the Breakpoints window displays the new breakpoint just like any other breakpoint, as shown below.

As soon as any of the functions in the Stack class are called, the debugger will stop at the function. Also, the Breakpoints window will show the fact that multiple breakpoints were set in the class. In the following screenshot, the function push() was called and the debugger stopped since there was a class breakpoint on the Stack class.

Habib Heydarian.

Troubleshooting common breakpoint problems in the Visual Studio debugger (Part I)

habibh — Wed, 02 Sep 2009 03:41:00 GMT

On the Visual Studio debugger team, one of the areas where we regularly receive feedback is when breakpoints don't work. Furthermore, some of the error messages that the debugger displays when a breakpoint fails are generic so it might be hard to diagnose why a breakpoint doesn't work correctly (we're working to improve these error messages). In this blog post and subsequent posts, I'm going to cover the most common reasons why breakpoints don't work in the Visual Studio debugger and provide potential workarounds.

Problem

When trying to set a breakpoint in a C# or VB method, you see the following error message:

The common language runtime was unable to set the breakpoint.

Description

This error occurs because the application that you are debugging is optimized and the method where you are trying to set the breakpoint has been optimized away and hence, doesn't exist in the running application. This typically happens if your project configuration is set to Release mode which enables the compiler setting to optimize code, as shown below. One way to fix this problem is to set the project configuration to Debug which disables optimizations.

Habib Heydarian.

How to debug a 64-bit dump using the Visual Studio debugger

habibh — Tue, 01 Sep 2009 04:48:00 GMT

One of the questions that comes up about debugging dump files is how to debug a dump file that was created from a 64-bit process. The reason why this question comes up is because Visual Studio itself is a 32-bit application and therefore, cannot debug a 64-bit dump file (or process). As a result, the first time that a developer tries to debug a 64-bit dump file, he (or she) typically runs across the following error message:

The 32-bit version of Visual Studio cannot debug 64-bit processes or 64-bit dumps. Please remote debug with the 64-bit version of Visual Studio Remote Debugging Monitor (MSVSMON.exe) instead.

To fix this problem, before you start debugging the dump file, run the 64-bit version of msvsmon.exe from %ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x64. However, even after doing so, you might see the following error message:

The version of this file is not compatible with the version of Windows you're running. Check you computer's system information to see whether you need an x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher.

Unfortunately, this error is rather confusing and doesn't tell you anything about the root cause. The problem here is that you are running a 32-bit operating system and therefore, cannot run a 64-bit process. Hence, you need a 64-bit operating system to run the 64-bit version of msvsmon.exe.

To summarize, in order to debug a 64-bit dump in the Visual Studio debugger, the following conditions need to be met:

You need a 64-bit version of Windows
You need to run the 64-bit version of msvsmon.exe first

Habib Heydarian.