Habib Heydarian's Blog @ Microsoft : VSTS Developing

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.

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.

Create your own Code Analysis rule set using Visual Studio Team System 2010

habibh — Wed, 12 Aug 2009 10:09:00 GMT

In a previous post, I explained how to use Code Analysis in Visual Studio 2010 to detect dead code. In that post, I described the following five Code Analysis rules in detail and how these set of rules form the basis for detecting dead code:

Private methods that are not called from any other code (CA1811)
Unused local variables (CA1804)
Unused private fields (CA1823)
Unused parameters (CA1801)
Internal classes that are not instantiated from any other code (CA1812)

To take this one step further, it would make sense to be able to treat this set of rules as one entity so I can manage all the rules for dead code detection as a single entity. In Visual Studio 2010, we have introduced the notion of a rule set that allows you to do exactly that.

What is a "rule set"?

Think of a rule set as a container or collection of rules. A rule set allows you to bundle one or more Code Analysis rules into an arbitrary category for easier management of those rules. For example, in Team System 2010, we are providing a number of rule sets out of the box:

Microsoft Security Rules
Microsoft Basic Correctness Rules
Microsoft Globalization Rules
etc.

How to create a rule set

For our walkthrough, we want to create a rule set called Dead Code Detection Rules that contains the five dead code detection rules mentioned above. The first step in creating a rule set is to create a new rule set file (*.ruleset). You can create a new rule set file via File –> New –> File. In this example, I've given the rule set the name DeadCodeDetectionRules.ruleset, as shown below.

After creating the rule set, set the name and description of the rule set using the Properties window, as shown in the following screen shot.

Since the rule set doesn't contain any rules yet, the rule set editor shows none of the rules as being checked. The rule set editor (shown below) is a new window in Visual Studio Team System 2010 that allows you manage rules and rule sets.

To start adding rules to the DeadCodeDetectionRules rule set, you can search for a rule using either the rule number or its name, as shown below. You can also simply expand the rule categories and select the rules that you are interested in.

After adding all five dead code detection rules, the rule set editor should look something like this:

Applying a rule set to a project

Once the rule set has been created, the next step is to apply the rule set to a project. This can be done via the Project Properties window. On the Code Analysis tab, click the dropdown next to the [Open] button and select "Browse..." to browse to the location of the rule set file. After selecting the rule set, the name and description of the rule set are shown in the summary page.

So now, all the dead code detection rules are part of a single rule set which make it much easier to manage, modify and apply the rules at both the project level as well as TFS policy level.

Habib Heydarian.

Visualize project dependencies with the Team System 2010 Architecture Explorer

habibh — Thu, 06 Aug 2009 10:56:00 GMT

As early as Visual Studio 2002, Visual Studio has supported the ability to see the dependencies between projects in a solution. However, the experience is somewhat clunky in that you can only see the dependencies one project at a time.

In the example below, you can see the project dependencies for the Patient Monitoring project. However, as I mentioned above, the major drawback to this approach is that you can only see the dependencies one project at a time and don't get to see a "global view" of your solution. There is also another scenario that today's solution doesn't solve. The problem is that the only way to find out why a dependency exists is to look at the code or use some other tool. In the screenshot below, the Project Dependencies dialog doesn't tell you why the Patient Monitoring project is dependent on the Chart project.

Architecture Explorer in Team System 2010 not only allows you to see the project dependencies for the entire solution but it also allows you to see the reason why each dependency exists. Each arrow in the screenshot below represents a dependency. Furthermore, the thickness of an arrow indicates the size of the dependency. Notice that there are no arrows going in or out of the ChartVisuals project. Using the Architecture Explorer, I discovered that this project is not being used anywhere!

To investigate a dependency further, you can expand the chevron (double arrows) on each node. This will not only display the classes within a project but it will also draw arrows from the classes that have dependencies on other projects. You can even dig one level deeper to see the methods in those classes that are calling into the dependencies. This is shown via the blue arrows below.

In a future blog post, I'll walk through how to use the Architecture Explorer to analyze circular references and class coupling.

Habib Heydarian.

PDC 2009: Developing Quality Software using Visual Studio Team System 2010

habibh — Wed, 05 Aug 2009 10:11:00 GMT

Software quality is a subject that is near and dear to my heart. At PDC 2009 this year, there is full day workshop on how to use Visual Studio Team System 2010 to develop high quality software. I'm really excited about this workshop since it covers a lot of the features that my team works on including the debugger, profiler, code analysis, Historical Debugger, code coverage, etc.

By the way, if you are heading down to PDC09, feel free to drop by the Visual Studio Team System booth for a chat. Who knows, I might also be giving a talk or two on the new developer features in Team System 2010.

Habib Heydarian.

How to debug an exception with the Visual Studio 2010 Historical Debugger

habibh — Wed, 05 Aug 2009 09:08:29 GMT

In a previous blog, I covered how to debug a LINQ to SQL query using the Historical Debugger. In this blog, I'll discuss using the Historical Debugger to debug an exception. The are a couple of reasons why the Historical Debugger is so useful when it comes to debugging exceptions:

If your application handles the exception (catches it), you can see where it occurred
You can see what happened before and after the exception. The ramifications of this capability are tremendous!
You can double-click on an exception and go directly in your code where the exception occurred or was handled.

Let's go through an example. In the following screenshot, you can see that there are a number exceptions that were both thrown and caught. This is indicated by the Exception: prefix.

Double-clicking on the exception above brings up the source window and displays the method where the exception occurred.

Last but not least, using the Debug History window, you can filter out all other events and only display exceptions, as shown below.

Habib Heydarian.

Catch string formatting bugs with Visual Studio Team System 2010

habibh — Tue, 04 Aug 2009 03:43:36 GMT

Formatting strings is a very common task in .NET development. Examples include formatting dates and currencies, composing a HTML response, creating error messages, etc. One of the downsides of string formatting is that if done incorrectly, you can end up with subtle bugs that won't be detected until runtime at which point, the application usually crashes with an exception.

Take the following code sample which comes from a real world application. It compiles fine and most of the time, it also runs without any problems However, once in a while, there is a customer complaint that the application crashes. It turns out that the if part of the code is rarely executed and because it isn't a common scenario, it wasn't tested.

So, what is the problem? If you look closely at line 6 below where the string body is formatted, the second format item which is supposed to be the user's name is missing. As I mentioned above, there is no compiler warning or error to tell the developer about this problem. It's usually found during testing or worse case, in production.

        1: protected void btnSubmit_Click(object sender, EventArgs e)

       2: {

       3:     if (isEditingPost)

       4:     {

       5:         string body = txtBody.Value;

       6:         body += string.Format("<p>-- {0}: post edited by {1}.</p>",

       7:            DateTime.Now.ToString());

       8:         // edit an existing post

       9:         Post.UpdatePost(postID, txtTitle.Text, body);

      10:         panInput.Visible = false;

      11:         panFeedback.Visible = true;

      12:     }

      13:     else

      14:     {

      15:         // Rest of code not shown

In Team System 2010, we have added a new rule to Code Analysis that detects this exact problem. When I run Code Analysis over the code above, it clearly warns me that I'm missing a format item:

warning: CA2241 : Microsoft.Usage : Method 'AddEditPost.btnSubmit_Click(object, EventArgs)' calls 'string.Format(string, object)' and does not provide an argument for format item "{1}". The provided format string is: '"<p>-- {0}: post edited by {1}.</p>"'

This feature is available in Visual Studio Team System 2010 Beta 1. Feel free to download the beta and if you have any feedback on this feature, please leave me a comment.

Habib Heydarian.

Discover dead code in your application using Code Analysis

habibh — Fri, 31 Jul 2009 16:04:23 GMT

Last weekend, I spent a good 30 minutes trying to figure out why I wasn't hitting a breakpoint in a method. Admittedly, I wasn't very familiar with the code since I hadn't written it. It turned out that the method wasn't being called from anywhere, so it was essentially "dead code". I wanted to remove the method in order to clean up the code but I wasn't 100% sure whether I would break anything. The only option was to use trial and error which meant that I commented out the method, rebuilt the code and ran through the scenario to verify that that the method was not being used. However, I still had a nagging feeling that maybe the code was being called through some other mechanism.

Well, it turns out that you can use Code Analysis to take out much of the guess work with it comes to dealing with dead code. But first, a definition is in order.

What is "dead code" anyway?

There are several definitions of dead code including i) redundant code ii) unreachable code and iii) unused code. Code Analysis in Visual Studio Team System can tell you about the following types of dead code:

Private methods that are not called from any other code (CA1811)
Unused local variables (CA1804)
Unused private fields (CA1823)
Unused parameters (CA1801)
Internal classes that are not instantiated from any other code (CA1812)

In the sections below, I'm going to explain each of these types of dead code using real world examples.

Private methods that are not called from any other code (CA1811)

This type of dead code is pretty easy to understand. If you have a private method that is not called from anywhere inside your class, Code Analysis will warn you about it, as shown here:

warning : CA1811 : Microsoft.Performance : 'SearchData.NotifyPropertyChanged(string)' appears to have no upstream public or protected callers.

In order to fix this issue, you can either add code to call the method or remove the method entirely. In the following example from the Patient Monitoring WPF sample application, the NotifyPropertyChanged private method is not called from any other code.

        1: private void NotifyPropertyChanged(string propName)

       2: {

       3:     if (PropertyChanged != null)

       4:     {

       5:         PropertyChanged(this, new PropertyChangedEventArgs(propName));

       6:     }

       7: }

Unused local variables (CA1804)

Typically, if you declare a local variable but don't assign anything to it, the compiler will warn you about it. However, if you do assign a value to the local variable, the compiler no longer complains even if you never use the variable. Take a look at the following example from the WPF Patient Monitoring sample application which declares and initializes the local variable dob but never uses it. This could be a real bug that should be investigated further.

       1: public SeriesDataItem(SeriesDataItems itemParent, double itemValue)

       2: {

       3:     _itemParent = itemParent;

       4:     DependencyObject dob = new DependencyObject();

       5:     this.SetValue(SeriesDataItem.ValueProperty, itemValue);

       6: }

Code Analysis will warn you about this type of dead code:

warning : CA1804 : Microsoft.Performance : 'SeriesDataItem.SeriesDataItem(SeriesDataItems, double)' declares a variable, 'dob', of type 'DependencyObject', which is never used or is only assigned to. Use this variable or remove it.

Unused private fields (CA1823)

In the example below, the field _filename is declared and initialized but it's not used anywhere in the assembly. Code Analysis will warn the developer with the following warning and also provides a suggestion as how to resolve the issue.

warning : CA1823 : Microsoft.Performance : It appears that field 'PatientVitals._filename' is never used or is only ever assigned to. Use this field or remove it.

This type of warning could be a bug in the code that should be investigated further.

       1: public class PatientVitals

       2:  {

       3:      private readonly char[] COMMA_SEPARATOR = new char[] { ',' };

       4:      private Dictionary<string, Waveform> _waveforms = new Dictionary<string, Waveform>();

       5:      private string _filename;

       6:  

       7:      public PatientVitals(string filename)

       8:      {

       9:          this._filename = filename;

      10:          this.ReadWaveformData(filename);

      11:      }

      12:  

      13:      // rest of class not shown

Unused parameters (CA1801)

This type of dead code might actually be a symptom of a real bug in the code. In the following example, the parameter nextValue is not used anywhere inside the method.

       1: private void ScrollPoints(double nextValue)

       2: {

       3:     DrawSeries();

       4:  

       5:     if (_chartPoints.Count == _chartPoints.Capacity)

       6:     {

       7:         _chartClock.Controller.SkipToFill();

       8:         _chartClock.Controller.Begin();

       9:     }

      10: }

It's always worrisome when a parameter is passed to a method but never used. If you have this type dead code, code analysis will warn you about it. It should definitely be investigated further.

warning : CA1801 : Microsoft.Usage : Parameter 'nextValue' of 'Chart.ScrollPoints(double)' is never used. Remove the parameter or use it in the method body.

Internal classes that are not instantiated (CA1812)

This type of dead code is much less common than the other types mentioned above. If you declare an inner class but do not instantiate it, Code Analysis will warn you with the following message:

warning : CA1812 : Microsoft.Performance : 'Order.OrderItem' is an internal class that is apparently never instantiated. If so, remove the code from the assembly. If this class is intended to contain only static methods, consider adding a private constructor to prevent the compiler from generating a default constructor.

In the following example, the inner class OrderItem is never instantiated from the Order class.

       1: public class Order

       2: {

       3:     private List<OrderItem> orderItems = new List<OrderItem>();

       4:  

       5:     public Order()

       6:     {

       7:     }

       8:  

       9:     private class OrderItem

      10:     {

      11:     }

      12: }

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.

Use UML Sequence Diagrams in Team System 2010 to reverse engineer your code

habibh — Wed, 29 Jul 2009 10:04:00 GMT

One of the new features that we have added in Visual Studio Team System 2010 is the ability to create a new UML Sequence Diagram as well as generate one from existing code. I'm not going to go into too much detail on what a UML sequence diagram is since there is a plethora of information about the subject on Wikipedia. Instead, I'm going to walk you through an example on how to generate a sequence diagram for an existing application using Team System 2010.

For this example, I'm going to use the BeerHouse sample application. BeerHouse contains a method (AddShoppingCartItem) which adds a product to the user's shopping code. The AddShoppingCartItem method is shown below.

public ActionResult AddShoppingCartItem(int productId, int? quantity)
{
    TheBeerHouseDataContext dc = new TheBeerHouseDataContext();
    ProfileBase profileBase = HttpContext.Profile as ProfileBase;
    ShoppingCart shoppingCart = (ShoppingCart)profileBase.GetPropertyValue("ShoppingCart");

    if (shoppingCart == null)
    {
        shoppingCart = new ShoppingCart();

        // get the cheapest shipping method for our user
        var cheapestShippingMethod = dc.ShippingMethods.GetShippingMethods().Cheapest();
        shoppingCart.ShippingMethod = cheapestShippingMethod;

        profileBase.SetPropertyValue("ShoppingCart", shoppingCart);
    }

    Product product = dc.Products.GetProduct(productId);

    // throw a 404 Not Found if the requested forum is not in the database
    if (product == null)
        throw new HttpException(404, "The product could not be found.");

    ShoppingCartItem item = new ShoppingCartItem(product) {
        Quantity = quantity ?? 1
    };

    shoppingCart.Add(item);

    return RedirectToAction("ViewShoppingCart");
}

You can certainly read through the code above to try and understand what it does. Alternatively, using a UML sequence diagram, you can visually see the sequence of calls within this method. To generate a sequence diagram, right-click anywhere inside the method (in this case AddShoppingCartItem) and select the "Generate Sequence Diagram" method, as shown below.

After selecting the Generate Sequence Diagram command, the "Generate a Sequence Diagram" dialog appears, as shown below. The purpose of this dialog is to allow you to control the amount of information that is displayed on the diagram. There are essentially three knobs to control the amount of information that is generated on the diagram: call depth, scope, namespace.

After clicking the [OK] button, the sequence diagram below is generated. It should be immediately clear how much easier it is to understand the sequence of method calls using the diagram instead of reading through the code.

In the diagram below, you can see that there are five objects involved and how the objects interact with each other. Also, there is a section marked Opt which stands for "optional" meaning that the sequence of calls within the Opt section are dependent on some condition being true (in this case when shoppingCart == null).

Tips

Here are a few tips for using sequence diagrams.

Changing the default name of a sequence diagram

By default, the name of the sequence diagram that is generated is cryptic and not very friendly. You cannot change the name on the diagram itself. Instead, you have to use the Properties window to change the Name property, as shown below.

Adding a comment to a sequence diagram

It's often helpful to annotate sequence diagrams by adding comments. To add a comment, right-click on the sequence diagram and select Add –> Comment.

As a last note, the ability to generate a UML sequence diagram is only supported for C# and VB.NET.

Habib Heydarian.

Walkthrough: Measure the performance of your JScript code with Team System 2010

habibh — Fri, 24 Jul 2009 22:41:02 GMT

In Visual Studio Team System 2010, one of the new features that we have added to the Profiler is the ability to measure the performance of JScript code that runs in the browser. This means that if you have a web application that contains ASP.NET AJAX or plain old JScript, you can now measure how long it takes to execute the JScript portion of the application. The main restriction with this feature is that it is only supported for Internet Explorer 8.

In this walkthrough, I'm using the BeerHouse sample application. Specifically, I want to measure the performance of the UpdateProgress() JScript function by figuring out how many times it is called. This function visually displays the current progress when a newsletter is sent to the list of subscribers. The body of UpdateProgress() is shown below.

        1: function UpdateProgress(result, context) 

       2: {

       3:    // result is a semicolon-separated list of values, so split it

       4:    var params = result.split(";");

       5:    var percentage = params[0];

       6:    var sentMails = params[1];

       7:    var totalMails = params[2];

       8:    

       9:    if (totalMails < 0)

      10:       totalMails = '???';

      11:    

      12:    // update progressbar's width and description text

      13:    var progBar = window.document.getElementById('progressbar');

      14:    progBar.style.width = percentage + '%';

      15:    var descr = window.document.getElementById('progressdescription');

      16:    descr.innerHTML = '<b>' + percentage + '% completed</b> - ' +

      17:       sentMails + ' out of ' + totalMails + ' e-mails have been sent.';

      18:    

      19:    // if the current percentage is less than 100%, 

      20:    // recall the server callback method in 2 seconds

      21:    if (percentage == '100')

      22:       window.document.getElementById('panelcomplete').style.display = '';

      23:    else

      24:       setTimeout('CallUpdateProgress()', 2000);

      25: }

And here is what the progress bar feature looks like.

To start collecting performance information about your application, select the "Launch Performance Wizard..." command from the Analyze menu, as shown here.

Once the Performance Wizard comes up, select the Instrumentation option and click [Next].

On the second page of the Performance Wizard, you can select which application you want to profile. Since I am profiling the BeerHouse application and it's already open in Visual Studio, the Profiler will automatically select the project for me, as shown below.

This next step is important! On the last page of the wizard, the checkbox to "Launch profiling after the wizard finishes" is checked. Uncheck it and click the [Finish] button.

After clicking the [Finish] button, Visual Studio will open the "Performance Explorer" window. In this window, under the "Targets" node, you can see the target application to be profiled . Right-click the target (in this case TBH_Web) and select Properties, as shown below.

In the Properties dialog, select the "Instrumentation" tab and check the "Profile JavaScript" option. Press [OK] to dismiss the dialog.

Next, in the Performance Explorer window, click the "Launch with Profiling" toolbar button to start collecting performance data about your application. See below for a screenshot.

This will launch the BeerHouse application and start collecting performance data. In order to capture information about the UpdateProgress() function, I need to exercise the feature by creating a newsletter and sending it to the subscribers of the BeerHouse web site. After completing the scenario, exit the application which will cause the profiler to stop collecting additional information about the application.

In the screenshot below, I've selected the "Call Tree" view to highlight information about the UpdateProgress() JScript function. As you can see from the screenshot, this function was called 12 times from the SendNewsletter.aspx page. The profiler not only shows how many times this function was called but also how long it took. Using this information, I can now make a decision as to whether to investigate this feature further or determine the performance is fine.

The steps shown in this walkthrough are applicable any time that you want to measure the performance of JScript code running in Internet Explorer 8. The JScript profiler feature is available as part of Visual Studio Team System 2010 Beta 1 which you can download from here.

Habib Heydarian.

The anatomy of the Historical Debugger Navigation Bar (Navbar)

habibh — Thu, 23 Jul 2009 23:52:30 GMT

In a recent Channel 9 10-4 video, Brian Keller introduced the Historical Debugger in Visual Studio Team System 2010. One of the features that he described in his video was the Historical Debugger Navigation Bar (Navbar) which he used to step back in the application.

In this post, I'm going to describe in detail what the navigation bar does and how to use it. Let's start with a screenshot of what I mean by the navigation bar.

The idea behind the Historical Debugger Navigation Bar is that you can use it to "time travel" through your application and go back and forward in your application to debug a problem. Think of it as the remote control for your Digital Video Recorder (DVR). You can rewind and fast forward as well as skip to sections of your application that you want to debug. The following screenshot shows what the individual controls on the Navbar do and the corresponding shortcut keys.

You can download Visual Studio Team System Beta 1 which includes the Historical Debugger. I've included the following sample code below so that you can use it to play around with the Historical Debugger. I'm always eager to hear your feedback.

using System;

class Program
{
    static void Main()
    {
        Sphere earth = new Sphere();
        double earthRadius = 3956.6; // miles
        double earthArea = earth.CalculateArea(earthRadius);
        Console.WriteLine("The area of earth is {0} square miles", earthArea);
    }
}

public class Circle
{
    // Area = PI * (R) ^ 2
    public double CalculateArea(double radius)
    {
        return (Math.PI * Math.Pow(radius, 2));
    }
}

public class Sphere
{
    // Area = 4 * Area of Circle
    public double CalculateArea(double radius)
    {
        Circle c = new Circle();
        return (4 * c.CalculateArea(radius));
    }
}

Habib Heydarian.