Creating and deploying Managed COM add-ins with VB.NET 2005 – Part I
I thought it would be of common interest to take a closer look into what VB.NET 2005 can offer when it comes to creating and deploying COM add-ins for Excel.
The evaluation will be in view of the following aspects:
– Creating a managed COM add-in
– Deploying a managed COM add-in
In order to create a useful tool I decided to challenge how to work with the Domino object class by using early binding to control Lotus Notes. The tool itself will make it possible to attach workbooks or worksheets to outgoing e-mails with Lotus Notes.
What does ‘Managed’ stand for?
All solutions that require the Common Language Runtime (CLR – part of the .NET Framework) are considered managed, which include all solutions developed with any tool in the Visual Studio.NET suite and with Visual Studio Tools for Office System (VSTO). Solutions developed with classic VB 6.0 and Excel’s VBA are unmanaged solutions.
Since Excel per se is an unmanaged environment we are, from a strictly technical point of view, about to create a managed solution which is supposed to be implemented on an unmanaged platform.
Anyway, for those of You who want to know more about the CLR the following URL provides a good introduction: The Common Language Runtime
Required tools and configuration
In order to create the COM add-in the following tools are required:
– Microsoft .NET Framework 2.0 and later *)
– The professional version of MS Visual Basic.NET 2005 and later in order to use the Shared Add-in template.
(Edit: It’s also available in the standard edition of VB.NET 2005. I don’t know if this template is available or not in the Express edition. It can be done without the template but that is beyond the scope of this post.)
– The Primary Interop Assemblies (PIA) for Microsoft Office 2003 *)
– Microsoft Excel 2003 and later *)
– Lotus Notes 7.01 and later in order to use the sample tool *)
*) Also required on the target computers in order to get the COM add-in to function properly.
Two important settings in VB.NET are:
Option Explicit On (Status by default)
Option Strict On (Not by default which force explicit narrowing conversions and also force early binding)
Compared with classic VB we have a quite large overhead to deal with on the client’s machine due to the requirements. In order to install the PIA for Office 2003 it requires that the .NET Framework is installed first. The .NET Framework is not shipped with Windows XP or with any previously versions. All in all, it will in general require an installation of both of them on the targeting computers.
Option Strict On is the recommended setting to which I agree with.
Unlike with classic VB we can only specify one Excel version the add-in should work with due to the involvement of the PIA (and implicit the existence of the .NET Framework). So if we want to develop an add-in for version 2002 and 2003 of Excel we actually need to develop two similar solutions where we use the version specific PIA in each solution. The same should be valid when it comes to Excel 2000 although there exist no official PIA for this version.
I recently raised a question about this issue at David Gainer’s blog and received an answer that MSFT will make it possible to develop add-ins that work with 2003 and forward.
Of course, this is a seriously limitation for managed add-ins as COM add-ins per se should not be version specific in the first place.
Update Your .NET copy
Before doing anything else it’s recommended that You download and install the following fix:
Add-ins, smart documents, or smart tags that you create by using Microsoft Visual Studio 2005 do not run in Office
When the project has been created make sure You add the fix to the prerequisites list as the following picture shows:
This is easiest done by right clicking on the SetUp project in the Solution Explorer Window and then select the menu option ‘Properties’.
In the next post we will take a closer look into the code to connect to Excel and create the custom commandbar .