Habib Heydarian's Blog @ Microsoft : Visual Studio 2008

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.

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.

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.

A few facts about the DinnerNow.net 3.1 sample application

habibh — Tue, 18 Aug 2009 11:31:00 GMT

Now that the DinnerNow.net 3.1 sample application has been released, I thought I'd share some information about the project to help developers learn more about DinnerNow.net and what they can expect after downloading it.

The following table summarizes the artifacts (source code, images, et.c) that make up the DinnerNow.net 3.1 sample application.

DinnerNow Artifact	Count
Number of solutions (including master solution)	12
Number of projects	37
Number of C# source files (*.cs)	356
Number of C# LOC (Lines Of Code) excluding comments	32,245
Number of ASPX/ASCX pages	12
Number of WCF services (*.svc)	9
Number of databases	3
Number of WPF forms (*.xaml)	15
Number of HTML pages (*.htm)	19
Number of CSS files (*.css)	10
Number of images (.gif, .jpg, *.png)	248

In a follow up post, I will discuss the overall architecture of DinnerNow.net and the structure of the solutions.

Habib Heydarian.

DinnerNow.net 3.1 for Windows 7 and Windows Server 2008 R2 released

habibh — Mon, 17 Aug 2009 10:03:00 GMT

DinnerNow.net 3.1 follows in the footsteps of the 3.0 release of DinnerNow.net by adding support for new Microsoft operating systems and platforms. New in DinnerNow 3.1 is support for Windows 7 and Windows Server 2008 R2. Also, DinnerNow 3.1 adds support for 64-bit operating systems and SQL Server 2008. For a complete list of new features in DinnerNow 3.1, see the sections below. To learn more about he DinnerNow sample application, visit the DinnerNow website.

You can download DinnerNow.net 3.1 from here.

1) Support for new Microsoft operating systems and technologies

DinnerNow.net 3.1 adds support for the following releases from Microsoft.

Windows 7 RTM (32-bit and 64-bit)
Windows Server 2008 R2 RTM (64-bit only)
Windows PowerShell 2.0
64-bit support for Windows Vista SP2 and Windows Server 2008 SP2
SQL Server 2008 Express Edition Service Pack 1 (32-bit and 64-bit)

NOTE: In version 3.1, support for SQL Server 2005 Express has been replaced with SQL Server 2008 Express SP1.

2) Bug fixes

DinnerNow 3.1 fixes the following issues.

Priority	Title
1	Detection logic for PowerShell installation is broken on Windows 7 and Windows Server 2008 R2
1	Fix setup to support installation on 64-bit
1	Windows Server 2008 R2: Dependency Checker crashes on startup.
1	64-bit: IIS Manager crashes when opening the Image Copyright control panel
1	64-bit: Images don't show up on the DinnerNow website
1	64-bit: In the AliasDatabaseServer project, some project references are broken
1	System.InvalidOperationException: The type '"DinnerNow.Services.OrderService', provided as the Service attribute value in the ServiceHost directive could not be found.
1	Build break: In SQL Server 2008, the type Microsoft.SqlServer.Management.Smo.Wmi.ServerAlias has moved from Microsoft.SqlServer.Smo.dll to Microsoft.SqlServer.SqlWmiManagement.dll
1	Windows 7: IIS Worker Process (w3wp.exe) doesn't have access to the DinnerNow.net databases.
1	Windows Server 2008 R2: Registering with CardSpace crashes the DinnerNow website.
1	DinnerNow 3.1 needs to support SQL Server 2008 Express Edition SP1
1	Windows 7: IIS installation script doesn't work
2	Unit Test "DinnerNow.Tests.MenuSyndicationServiceTest.GetRestaurantAtomTest" fails with System.Net.WebException
2	TestOrderProcessWorkflow: Unit Test fails with System.InvalidOperationException
2	GetRestaurantRssTest: Unit Test fails with System.Net.WebException
2	GetRestaurantCategoriesWCFTest: Unit Test fails with System.InvalidOperationException

As always, your feedback is welcome.

Habib Heydarian.

How to detect the .NET Framework directory using PowerShell

habibh — Wed, 12 Aug 2009 01:41:16 GMT

As 64-bit machines become mainstream, one of the problems that developers run into is dealing with registry keys and directories. This is because many applications and runtimes are designed to run on both 64-bit and WOW64. The problem comes about because the same application or runtime is installed in two different directories or has two separate entries in the Windows Registry (both 32-bit version and 64-bit version).

Take the .NET Framework for example. On a 64-bit operating system, the 32-bit version of the framework is installed in

C:\Windows\Microsoft.NET\Framework\v2.0.50727

while the 64-bit version of the framework on the same machine is installed in:

C:\Windows\Microsoft.NET\Framework64\v2.0.50727

To take this example further, let's say that as part of your application's setup, you have hard-coded the location of the .NET Framework. There is a good chance now that when you migrate your application to 64-bit, your setup application is broken.

If you are using PowerShell as part of your setup application, you can detect the directory of the .NET Framework, as shown below. The Get-FrameworkDirectory cmdlet returns the default .NET Framework directory regardless of whether you are running on 32-bit or 64-bit.

function Get-FrameworkDirectory()
{
    $([System.Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory())
}

In the sample below, I'm using the Get-FrameworkDirectory cmdlet to find the location of aspnet_regsql.exe.

function Create-SQLASPNETMembership
{
    Write-Host "Create the ASPNETDB SQL Server database for the membership system"
    $frameworkDir = Get-FrameworkDirectory
    Set-Alias aspnet_regsql (Join-Path $frameworkDir "aspnet_regsql.exe")
    aspnet_regsql -S DinnerNow -E -A all    
}

Habib Heydarian.

Just released: Patch to make NetCFSvcUtil.exe work on Windows 7 (and other operating systems)

habibh — Mon, 10 Aug 2009 10:31:00 GMT

In an earlier blog post, I mentioned that NetCFSvcUtil.exe (available as part of Power Toys for .NET Compact Framework 3.5) is broken on the following operating systems:

Window 7 RTM
Windows Server 2008 R2
Windows Vista SP2
Windows Server 2008 SP2

Specifically, when you try to run NetCFSvcUtil.exe on these operating systems, you might see the following error message:

Error: An error occurred in the tool.

Error: Error in the application.

The good news is that the Windows Mobile Developer team released a patch today that fixes this problem. You can download the new version of NetCFSvcUtil from here.

Habib Heydarian.

Windows 7 RTM Training Kit For Developers is here!

habibh — Fri, 07 Aug 2009 10:02:00 GMT

If you are a developer and you are planning to write applications for Windows 7, then one of the best places to start is the Windows 7 Training Kit For Developers which was released today.

The Window 7 Training Kit has everything you need to get started with programming Windows 7, including sample code, videos, presentations, Hands-On Labs (HOLs), etc. Most of the samples come with Visual Studio 2008 projects which means that you can open and debug these samples in Visual Studio 2008!

The training kit has a few prerequisites. Once you download the training kit, click the Prerequisites link to navigate to the page where you can download all the prerequisites.

Habib Heydarian.

Debugging 101: How to skip over code in the Visual Studio Debugger

habibh — Thu, 30 Jul 2009 10:37:00 GMT

One of the questions that comes up regularly on newsgroups is "How do I skip over a section of my code in the Visual Studio debugger?" The answer depends on the meaning of the word "skip" but in general, there are three ways that you can skip over a section of code in the debugger. I'll describe these three techniques using the following code sample.

        1: public bool DecrementUnitsInStock(int quantity)

       2: {

       3:    bool success = Product.DecrementProductUnitsInStock(this.ID, quantity);

       4:    if (success)

       5:       this.UnitsInStock -= quantity;

       6:    return success;

       7: }

Step Over (F10)

Step Over (F10) is by far the most well known command for skipping over an entire method but still execute the function that you are stepping over. When you Step Over a line, it executes all method calls that are on that line (including methods that take other methods as their argument) and stop on the next line. However, if any of the methods that you are stepping over contain a breakpoint or throw an exception, the debugger will stop in the method.

In the screenshot below, pressing F10 will execute the DecrementProductUnitInStock() method without tracing through it and will stop at the next line.

Run To Cursor (CTRL+F10)

Think of Run To Cursor as an "invisible one-shot breakpoint". What does that mean exactly? It means that just like a breakpoint, the debugger will execute your application up to where your cursor is and break. In the following example, I placed my cursor on the line "return success" and pressed CTRL+F10. The debugger ran all the code up to (but excluding) the line "return success" and stopped.

Run To Cursor is very useful when it comes to skipping over parts of a function that you don't want to step through. For example, if you have a loop in your method and you don't want to step through the loop, set your cursor just after the loop and select Run To Cursor (CTRL+F10).

Set Next Statement (CTRL+SHIFT+F10)

Set Next Statement is a powerful debugging feature for controlling application execution, granted that it's used correctly. If used incorrectly, it can lead to all sorts of weird and wonderful behavior in your application. In a nutshell, Set Next Statement allows you to jump around in a method without executing any code in between. In the code segment below, I moved the yellow arrow to the "return success" line which means that I skipped the execution of the if statement.

Set Next Statement is frequently used in conjunction with edit and continue. That is, after changing some code during the debug session, you can set the next statement to the location before the change and re-execute the code to see the affect of your changes.

Also, instead of using the shortcut CTRL+SHIFT+F10, you can drag the yellow arrow to the location in your code that you want to execute.

If you use other techniques to skip over code in the debugger, feel free to leave a comment.

Habib Heydarian.

Quick Tip: How to move a breakpoint in the Visual Studio debugger

habibh — Wed, 29 Jul 2009 04:38:18 GMT

Setting a breakpoint in the Visual Studio debugger is as simple as placing your cursor on a line of code and pressing F9. However, once you've set the breakpoint, how do you move it to a different location since clicking on the breakpoint will delete it? One workaround is to delete the breakpoint and set a new breakpoint at the new location. The problem is, if you have set a bunch of options on the breakpoint, e.g. a condition, then those options will get lost in the move.

The trick to moving a breakpoint is to use the Breakpoint Location option to change the line number of the breakpoint. You can access the Location option by right-clicking on the breakpoint the you want to move and selecting "Location...", as shown below.

On the File Breakpoint dialog, simply change the Line field to the new location and press [OK]. The breakpoint will move to the new location.

Habib Heydarian.

The Visual Studio Output window: It has more to offer than meets the eye

habibh — Wed, 22 Jul 2009 14:54:11 GMT

At first glance, the Visual Studio Output window appears to be a boring tool whose only role in life is to display status information. However, look more closely and you will find that it provides several features that can be extremely useful. Below, I’ve listed the most common scenarios where I use the Output window.

Search

Probably the most common reason for why I use the Output window is because of search. Not many people know this but you can search the Output window just like any other text editor. To search in the Output window, put your cursor in the window and press CTRL+F. The Find dialog comes up and you can search for any string. Why is this so useful you ask? The main reason is that you can search through output from the compiler, Code Analysis, your own program (think output from Debug.WriteLine) or any other tool that displays its output in the Output window. This basically makes up for not being able to search the Error List.

Navigation

Just like the Error List, you can double-click on an error or warning in the Output window and navigate to it in the source code. There is no visual cue to suggest that you can double-click on a message. You just can!

Automatic log file

During debugging, since all the output from an application goes to the Output window, I often use the Output window as a log file. Specifically, at the end of the debug session, you can put your cursor in the Output window and press CTRL+S to save the output as a text file. No copy and past required!

If you use the Output window for other purposes, feel free to leave me a comment.

Habib Heydarian.

How to install and configure the DinnerNow.net 3.0 sample application [Video]

habibh — Mon, 20 Jul 2009 10:02:00 GMT

About two weeks ago, version 3.0 of the DinnerNow.net sample application was released and I covered the release in this blog. Since then, there have been close to 800 downloads of the application. To help people ramp up on DinnerNow, I've created a short video that shows how to install and configure DinnerNow.net 3.0.

There are basically four steps to setup DinnerNow.net 3.0:

Step 1: Download and install DinnerNow.net
Step 2: Configure and Build DinnerNow.net
Step 3: Open the DinnerNow.net solution inside Visual Studio
Step 4: Verify that the DinnerNow application works

The following video walks through the steps above and discusses the areas to watch out for.

If you run into any issues installing DinnerNow.net 3.0, feel free to send feedback via the Discussion forum on the DinnerNow web site.

Habib Heydarian.

Walkthrough: Debug a WPF window or Windows Form without running your application [Video]

habibh — Fri, 17 Jul 2009 10:52:00 GMT

Most Windows GUI applications share a common trait. They all have multiple forms and/or dialogs. In the screenshot below, this simple application alone has four WPF windows.

If I want to debug the main window, that's easy. I just press F5 and the main window or form starts up. However, if I want to debug one of windows or dialogs that are displayed as a result of clicking a button in my application, it requires me to i) start my main application and ii) click through various windows and dialogs until I get to the window that I'm interested in.

This is both tedious and can be time consuming. There is a much easier way to debug a window or form, without having to start the debugger and clicking through the application.

Watch the video below for a walkthrough.

This feature is available for both C# and VB. Feel free to drop me a line if you are using this feature today.

Habib Heydarian.