How to debug a Visual Studio .NET 2005 Add-In

In Visual Studio .NET 2002 and Visual Studio .NET 2003, you were required to register add-in assemblies with Windows as COM components by using the Assembly Registration Tool (regasm.exe). Also, you were required to register the add-in with Visual Studio by using keys in the Windows registry before the add-in would appear in the Add-In Manager.

These steps have changed in Visual Studio 2005. You no longer need to register the .NET assemblies with Windows by using regasm. Instead, you simply place the assembly .DLL file into a specific directory along with an XML file that has an .Addin file extension. This XML file describes the information that Visual Studio requires to display the add-in in the Add-In Manager. When Visual Studio starts, it looks in the .Addin File location (listed below) for any available .Addin files. If it finds any, it reads the XML file and provides the Add-In Manager with the information needed to start the add-in when it is clicked.

This simplified registration method allows XCopy-style installations for managed code add-ins. If you put all the files in the right place, then your add-in works just fine. Also, its use of commented XML to define the registration settings for add-ins allows the information to be more easily understood and edited than registry keys.

Application Configuration

However for debugging an add-in you have to one other thing. In the Debug tab you have to select an external program which will start a new development environment . This application can handle command-line arguments. The argument for resetting an add-in is resetaddin which expects a full class name.

Debug Configuration

The following is an example of a complete .Addin XML file. The .Addin file is usually placed at /Documents and Settings/All Users/My Documents/Visual Studio 2005/Addins or /Documents and Settings/<user name>/My Documents/Visual Studio 2005/Addins. The Assembly node (in bold) specifies the location of the (debug) add-in binaries. This field can be set to a local path, a network path, or a valid URL.

<?xml version="1.0" encoding="UTF-16" standalone="no"?>

<Extensibility xmlns="http://schemas.microsoft.com/AutomationExtensibility">

  <HostApplication>

    <Name>Microsoft Visual Studio</Name>

    <Version>8.0</Version>

  </HostApplication>

  <Addin>

    <FriendlyName>w00t</FriendlyName>

    <Description>w00t</Description>

    <Assembly>[Path to add-in]/w00t.dll</Assembly>

    <FullClassName>MGlaser.Tools.w00t.Connect</FullClassName>

    <LoadBehavior>1</LoadBehavior>

    <CommandPreload>0</CommandPreload>

    <CommandLineSafe>0</CommandLineSafe>

  </Addin>

</Extensibility>

w00t - For Testing.AddIn

Summary
It's really easy to debug an add-in these days. The reason why I want to show you this cause one of mine w00test add-ins doesn't work in mine virtual PC images. I hope to bring you the good news tommorow if I was able to extend this add-in, so it can work on a VPC as well.