B# .NET Blog : Visual Studio 2005

Writing custom Visual Studio 2005 Debugger Visualizers

bart — Wed, 04 Apr 2007 10:50:50 GMT

A little-known feature in Visual Studio 2005 is the possibility to create a custom debugger visualizer. In this post, we'll take a closer look at this feature. A debugger visualizer allows you to associate a custom control or Windows Form with an object type definition in order to visualize that particular type in a user-friendly fashion while debugging in Visual Studio 2005. Assume the following type definition:

    public class Bar
    {
        private string name;
        private int age;
        private string secret = "Foo";

        public Bar(string name, int age)
        {
            this.name = name;
            this.age = age;
        }

        public string Name
        {
            get { return name; }
            set { name = value; }
        }

        public int Age
        {
            get { return age; }
            set { age = value; }
        }

        public string Secret
        {
            get { return secret; }
            set { secret = value; }
        }
    }

Assume a simple application that does the following:

 1     public partial class Form1 : Form
 2     {
 3         public Form1()
 4         {
 5             InitializeComponent();
 6         }
 7 
 8         private void button1_Click(object sender, EventArgs e)
 9         {
10             Bar b = new Bar("Bart De Smet", 24);
11         }
12     }

Set a breakpoint on line 11 and execute the application using the debugger. Normally you'll see something like this:

Observe the zoom glass icon displayed next to the strings name and secret. If you click the arrow at the right of it, you see this:

These three, the "Text Visualizer", "XML Visualizer" and "HTML Visualizer", are so-called debugger visualizers. What we want to do, is to create such a visualizer for our Bar type. In order to do so, add a new item to the project and choose for the Debugger Visualizer template type and call it BarVisualizer:

Change the code as follows:

    public class BarVisualizer : DialogDebuggerVisualizer
    {
        protected override void Show(IDialogVisualizerService windowService, IVisualizerObjectProvider objectProvider)
        {
            Bar data = (Bar)objectProvider.GetObject();
            windowService.ShowDialog(new BarVisualizerControl(data));
        }
    }

    [DebuggerVisualizer(typeof(BarVisualizer), Description = "Bar Visualizer")]
    [Serializable]
    public class Bar
    {
        private string name;
        private int age;
        private string secret = "Foo";

        public Bar(string name, int age)
        {
            this.name = name;
            this.age = age;
        }

        [Browsable(true), Category("Author"), Description("Name of the author")]
        public string Name
        {
            get { return name; }
            set { name = value; }
        }

        [Browsable(true), Category("Author"), Description("Age of the author")]
        public int Age
        {
            get { return age; }
            set { age = value; }
        }

        [Browsable(false)]
        public string Secret
        {
            get { return secret; }
            set { secret = value; }
        }
    }

For the Bar type, observe we've added a few attributes from System.ComponentModel to make these display properly in a PropertyGrid control, as shown below. More specifically, these attributes give the properties a friendly name, as well as a category. The Secret property won't be displayed because we set it's browsable attribute to false.

The most important portion however, is the DebuggerVisualizer attribute on top of the class, telling the VS2005 debugger which type to load as the debugger visualizer for the type. Our visualizer, BarVisualizer, creates a new BarVisualizerControl instance to show the object. It's defined like this:

This user control simply contains a (.NET 2.0) PropertyGrid object, called propertyGrid1. The code behind contains the following:

    public partial class BarVisualizerControl : UserControl
    {
        public BarVisualizerControl(Bar bar)
        {
            InitializeComponent();
            propertyGrid1.SelectedObject = bar;
        }
    }

Congratulations, your first debugger visualizer is ready! Run the application in the debugger with the breakpoint set as mentioned earlier and observe the visualizer being available in the VS2005 debugger:

When you click the visualization icon, the following appears:

Nice, isn't it? Of course, you could create much more complicated debugger visualizers that host a bunch of functionality. Just to give you an idea, think of a visualizer for a database connection kind of class that allows to test the connection using the settings available, or to open up a query creationtool to run against the connectionto check whether or not authorization to certain tables or sprocs works correctly for the given connection settings.

Furthermore, you can also attach a visualizer to a type you don't maintain yourself, by using the [assembly: DebuggerVisualizer(...)] attribute inside a class library project. Compile the project and copy the DLL file to the %programfiles%\Microsoft Visual Studio 8\Common7\Packages\Debugger\Visualizers folder. An example is shown below:

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Windows.Forms;
using Microsoft.VisualStudio.DebuggerVisualizers;

[assembly: DebuggerVisualizer(typeof(MyVisualizers.StringVisualizer), typeof(VisualizerObjectSource), Target = typeof(string), Description = "My String Visualizer")]

namespace MyVisualizers
{
    public class StringVisualizer : DialogDebuggerVisualizer
    {
        protected override void Show(IDialogVisualizerService windowService, IVisualizerObjectProvider objectProvider)
        {
            string data = (string)objectProvider.GetObject();
            using (Form f = new Form())
            {
                f.Text = data;
                windowService.ShowDialog(f);
            }
        }
    }
}

Notice you can also change the object through the visualizer; have a look at the IVisualizerObjectProvider's ReplaceObject and TransferObject methods, as well as the IsObjectReplaceable read-only property.

Have fun!

Team Foundation Server and fully qualified domain names

bart — Tue, 20 Feb 2007 12:28:01 GMT

For the moment, I'm responsible to set up a TFS machine for a team project that's performed over the internet. No big deal you might think? Well, there are some issues that you have to beware of.

The most 'difficult' one is the "fully qualified domain name" issue. When you install TFS, quite a bunch of references to the machine are kept as the NETBIOS name (e.g. TFSLAB01). These references are used by lots of services (e.g. a page called tfsredirect.aspx will use a registry setting to gather reports in the SharePoint environment) as well as the Team Explorer clients (for which settings are obtained via and exported through a web service call to the TFS machine).

As you can imagine, the server naming above does work out for intranet scenarios but on the internet a name like TFSLAB01 is worthless. There are a few solutions to this:

Have every team member connect to the company over VPN.
Modify the hosts file on each team member's dev box by adding an entry that points TFSLAB01 (the TFS server name) to the right IP.
Change some settings on the TFS machine to use the FQDN. Read Mike Glaser's blog entry for more information.

Have fun!

Visual Studio tip - select a rectangular block of code

bart — Sun, 18 Feb 2007 00:30:22 GMT

A little tip but definitely a time-saver in case you didn't know about it yet... Quite a bit of Word users should be familiar with this one:

What I'm talking about is ALT+mouse selection (any official marketing name for this feature out there?). Guidelines: hold the ALT button on the keyboard and make a selection with the mouse; you'll be able to select a "rectangular block" of text. But did you know it's out there in Visual Studio too?

The reason for this post: recently a reader of my blog complained about the line numbering in my code samples:

 1 using System;
 2 using System.Collections.Generic;
 3 using System.Text;
 4 
 5 namespace RunspaceDemo
 6 {
 7     class Class1
 8     {
 9         public void Bar()
10         {
11             Console.WriteLine("Hi there");
12         }
13     }
14 }

When copying this piece of code to Visual Studio, you'll see something like this:

Of course, you could manually delete all of the line numbers. However, using ALT+select this becomes much easier:

Just press Delete and you're ready to go!

Visual Studio 2005 SP1

bart — Fri, 15 Dec 2006 16:20:37 GMT

Finally, it's here: download now.

Sandcastle December 06 CTP

bart — Sun, 10 Dec 2006 21:25:44 GMT

I blogged about Sandcastle in the past, over here. You can grab the December 06 CTP from the Microsoft-website now. Take a look at the Sandcastle MSDN Blog too.

Fun with MPPG/MPLex - Visual Studio 2005 SDK version 3.0

bart — Sun, 22 Oct 2006 08:49:00 GMT

Did you know the third version of the Visual Studio 2005 SDK was shipped about one month ago? I missed this one out for a while, so it's time to explore it right now. Check out Somasegar's WebLog too for information on it.

One great thing in there is the MPPG/MPLex parser/lexer twin (just like yacc/lex or bison/flex) sample that comes with the SDK. I saw this project (called GPPG) from Queensland University quite a while ago (after attending the Good For Nothing Compiler session at the PDC last year) and have been skimming over it because of my interest in compilers. The big difference with yacc/lex is the output language, which is C# instead of C.

As you might already know by now, I spend a lot of my free time on the "dark side", inside the runtime (cf. SSCLI), messing around with specs (cf. ECMA-335) and having fun with compiler technology (cf. some-personal-project-without-a-name). I'll try to blog about MPPG/MPLex experiences in the near future.

If this isn't something to spend your Sunday afternoon on ...

Bart De Smet - Ghent - 10/12/06 1:55 (deferred post)

Visual Studio Team Edition for Database Professionals (aka DataDude) CTP 6

bart — Wed, 18 Oct 2006 20:05:00 GMT

Gert Drapers, development manager for DataDude and SQL guru for life, announces the availability of CTP6 on his blog. Also notice the RTM release is scheduled for Q1 2007.

For the Belgians not attending TechEd IT Forum (most developers don't I guess, but there are exceptions like me), Gunther Beersaerts will deliver an MSDN Evening Session on November 15, 2006: Introducing Visual Studio Team Edition for Database Professionals.

Time to become datadudes, don't we?

Visual Studio 2005 SP1 Beta available

bart — Wed, 27 Sep 2006 00:54:00 GMT

Rather unexpectedly, the availability of a SP1 beta for Visual Studio 2005 was announced today by soma. As usual, everyone is welcome to join the beta programme on Microsoft Connect. Enjoy!

An ASP.NET .ashx HTTP handler for Code 39 barcode generation

bart — Tue, 19 Sep 2006 09:21:00 GMT

Introduction

In my previous blog post on Code 39 barcodes, I've shown you guys how to generate Code 39 barcodes using managed code. Today, we'll take it another step forward and make barcode generation available through an .ashx ASP.NET 2.0 HTTP handler.

About ASP.NET 2.0 Generic Handlers

One of the great things in ASP.NET is the concepts of "generic handlers". Basically you can look at it as just another kind of object that can process HTTP requests, however outside the scope of a page (which targets 'classic' HTML-based output). You might have heard about HTTP handlers too and basically these are the same except for the fact that you can bind an HTTP handler to any file extension (as long as you IIS configuration permits) whileas a generic handler just lives behind the .ashx extension and is directly supported in Visual Studio 2005 web site projects. In the end all handlers implement System.Web.IHttpHandler. Last but not least, you'll be able to host any ASP.NET HTTP Handler directly in IIS 7 too (which I'll blog about later on).

Our online Code39 barcode generator

First of all create a new web site project in Visual Studio 2005:

Next, add a new generic handler called "Code39Generator.ashx" to the project:

This will generate the following piece of code:

<%@ WebHandler Language="C#" Class="Code39Generator" %>

using System;
using System.Web;

public class Code39Generator : IHttpHandler {
   public void ProcessRequest (HttpContext context) {
      context.Response.ContentType = "text/plain";
      context.Response.Write("Hello World");
   }

   public bool IsReusable {
      get {
         return false;
      }
   }
}

Exactly, "Hello World" made it to the built-in code snippets in Visual Studio 2005. Our task is to create a suitable ProcessRequest method that returns an image with a requested barcode. Requested by means of the querystring that is. The IsReusable property is used by the ASP.NET runtime to find out whether the instance of our handler can be reused for multiple requests. That's fine for us, as we don't have intentions to turn our handler instance to garbage once a request has passed through the pipeline:

   public bool IsReusable {
      get {
         return true;
      }
   }

On to the real stuff now. First of all make sure the Code39 and Code39Settings classes (see previous post) are available in the context of the web site project. You can do that by CTRL-C,V-ing the code to a class file or by referencing a class library project. I've chosen to walk the former path as shown below:

Make sure to declare the classes as follows:

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Drawing;
using System.Drawing.Imaging;

public class Code39Settings
{
...
}

public class Code39
{
...
}

Back to our .ashx file. First let's fix some namespace imports:

using System;
using System.Web;
using System.IO;
using System.Drawing;
using System.Drawing.Imaging;

Real stuff happens a little further, in the ProcessRequest method which we define like this:

public void ProcessRequest(HttpContext context)
{
   string code = context.Request["code"];
   if (code != null)
   {
      Image img = new Code39(code.ToUpper()).Paint();
      context.Response.ContentType = "image/png";
      byte[] b = GetImageBytes(img);
      context.Response.OutputStream.Write(b, 0, b.Length);
   }
}

The basic idea is simple: just take the generated image from our Code39 class's Paint method and send it back to the client as an image/png type of HTTP response. In order to do so, we'll need the bytes of the image.

Note: It would be easier if we could write this:

img.Save(context.Response.OutputStream, ImageFormat.Png);

However this causes the following exception to occur:

[ExternalException (0x80004005): A generic error occurred in GDI+.]
   System.Drawing.Image.Save(Stream stream, ImageCodecInfo encoder, EncoderParameters encoderParams) +568
   System.Drawing.Image.Save(Stream stream, ImageFormat format) +33
   Code39Generator.ProcessRequest(HttpContext context) +157
   System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +390
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +65

There are lots of forum threads on this issue (just Live Search for it), most of which have to do with permissions when trying to save images on the server's disk. However, I decided to create a code-based workaround as I have some indications permissions might not be the issue in this case (and even if they were, I rather like to have the solution just work in xcopy deployment scenarios). Therefore, here it is, the GetImagesBytes method:

private byte[] GetImageBytes(Image image)
{
   ImageCodecInfo codec = null;

   foreach (ImageCodecInfo e in ImageCodecInfo.GetImageEncoders())
   {
      if (e.MimeType == "image/png")
      {
         codec = e;
         break;
      }
   }

   using (EncoderParameters ep = new EncoderParameters())
   {
      ep.Param[0] = new EncoderParameter(Encoder.Quality, 100L);

      using (MemoryStream ms = new MemoryStream())
      {
         image.Save(ms, codec, ep);
         return ms.ToArray();
      }
   }
}

This one just works fine. So, press F5 to run the web site project and see the ASP.NET Development Server getting ready to serve you:

Right-click the icon and choose "Open in Web Browser" if the system didn't do this already by itself. You should see the directory listing now:

Click the Code39Generator.ashx file and patch the browser address bar by appending ?code=BART to it (e.g. http://localhost:49587/Code39/Code39Generator.ashx?code=BART - the port will much likely be different on your machine). There we go:

Stay tuned for even more barcode fun soon!

Conditional compilation in C# - explaining System.Diagnostics.ConditionalAttribute

bart — Thu, 31 Aug 2006 05:04:00 GMT

Introduction

Conditional compilation is one of the much unknown powerful features that are available in .NET and more specifically in the C#, VB.NET and J# compilers. In this post, I'd like to show you how to take benefit from this feature, applied to C#.

An example

using System;
using System.Diagnostics;

class Program
{
   static void Main(string[] args)
   {
      DebugLog("Before loop");

      for (int i = 0; i < 10; i++)
         Console.WriteLine(i);

      DebugLog("After loop");
   }

   [Conditional("DEBUG")]
   private static void DebugLog(string s)
   {
      Console.WriteLine(s);
   }
}

First compile the program using one of the following options:

In Visual Studio 2005 with the active configuration set to Debug.
On the command-line using csc /define:DEBUG Program.cs. (Note: this is not the same as csc /debug+ Program.cs)
Add #define DEBUG in the program code.

When you execute the program, you'll see:

Before loop
0
1
2
3
4
5
6
7
8
9
After loop

In the IL code you'll see something like this:

IL_0000: nop
IL_0001: ldstr "Before loop"
IL_0006: call void Program::DebugLog(string)
IL_000b: nop
IL_000c: ldc.i4.0
IL_000d: stloc.0
IL_000e: br.s IL_001b
IL_0010: ldloc.0
IL_0011: call void [mscorlib]System.Console::WriteLine(int32)
IL_0016: nop
IL_0017: ldloc.0
IL_0018: ldc.i4.1
IL_0019: add
IL_001a: stloc.0
IL_001b: ldloc.0
IL_001c: ldc.i4.s 10
IL_001e: clt
IL_0020: stloc.1
IL_0021: ldloc.1
IL_0022: brtrue.s IL_0010
IL_0024: ldstr "After loop"
IL_0029: call void Program::DebugLog(string)
IL_002e: nop
IL_002f: ret

Nothing special going on despite the declaration of the [Conditional("DEBUG")] attribute. However, let's compile the same application now as a release build:

In Visual Studio 2005 with the active configuration set to Release.
On the command-line using csc Program.cs.

Now the output will be:

0
1
2
3
4
5
6
7
8
9

and the corresponding IL is:

IL_0000: nop
IL_0001: ldc.i4.0
IL_0002: stloc.0
IL_0003: br.s IL_0010
IL_0005: ldloc.0
IL_0006: call void [mscorlib]System.Console::WriteLine(int32)
IL_000b: nop
IL_000c: ldloc.0
IL_000d: ldc.i4.1
IL_000e: add
IL_000f: stloc.0
IL_0010: ldloc.0
IL_0011: ldc.i4.s 10
IL_0013: clt
IL_0015: stloc.1
IL_0016: ldloc.1
IL_0017: brtrue.s IL_0005
IL_0019: ret

So, no single call to the DebugLog method was emitted in the Main's code. Powerful isn't it? The coolest thing about all this is that you don't have to decorate your code using a bunch of #if statements, like this:

   static void Main(string[] args)
   {
#if DEBUG
      DebugLog("Before loop");
#endif

      for (int i = 0; i < 10; i++)
         Console.WriteLine(i);

#if DEBUG
      DebugLog("After loop");
#endif
   }

One advantage of the latter approach might be that you can also #if DEBUG ... #endif the DebugLog method itself. Using conditional compilation the DebugLog method will get compiled no matter what.

A few remarks to conclude:

The ConditionalAttribute can only be applied to methods and to attribute classes (that is: classes that derive from System.Attribute). Thus property and event accessors can't be decorated using this attribute.
The Debug and Trace classes of the .NET Framework use the ConditionalAttribute. So you don't have to worry about any performance hit whatsoever when you call various methods of these classes as a debugging aid. These calls just won't make it in the release build (or better: non-debug builds), e.g.:

[Conditional("DEBUG")]
public static void Assert (
bool condition
)
The C++ compiler doesn't support the ConditionalAttribute; you'll have to rely on #if conditionals to include/exclude debugging code.
The ConditionalAttribute allows multiple decorations per method (or attribute class):

[AttributeUsageAttribute(AttributeTargets.Class|AttributeTargets.Method, AllowMultiple=true)]

Therefore you can do things such as (cf. section 17.4.2.2 of the C# specification):

   [Conditional("ALPHA")]
   [Conditional("BETA")]
   private static void DebugLog(string s)
Attribute decorations are emitted to the metadata of a class. Because of this, you can get ConditionalAttribute working across languages and assemblies. An example of a class definition in C#:

public static class Helper
{
   [Conditional("DEBUG")]
   public static void DebugLog(string s)
   {
      Console.WriteLine(s);
   }
}

and its usage in VB:

Class Program
   Shared Sub Main()
      Helper.DebugLog("Before loop")

      Dim i As Integer
      For i = 0 To 10
         Console.WriteLine(i)

      Helper.DebugLog("After loop")
   End Sub
End Class

This will yield the same result as the C# only example, because the VB compiler can find out (using the metadata of class Helper) that calls to DebugLog should only be made when a DEBUG build is made.

References

More information on the ConditionalAttribute can be found in the MSDN Library.
The C# compiler reserved attributes can be found in section 17.4 of the C# specification.

Enjoy!