In last October's column, I demonstrated how to use Microsoft� Visual Studio� .NET to create console applications, Windows Forms applications, Web Forms applications, and XML Web services that interact with Microsoft Office. In this month's column, I will show you how to create an Office managed COM add-in using Visual Studio .NET.

Before COM add-ins were invented, you could only create Office application-specific add-ins (except Microsoft Outlook� and Microsoft FrontPage�). These application-specific add-ins have file extensions such as .mda, .pwz, .wll, and .xla; some examples of Office application-specific add-ins are the Analysis ToolPak and the Solver Add-In for Microsoft Excel. Starting with Microsoft Office 2000, COM add-ins allow you to create add-ins that span multiple Office applications. This allows you to write code that is common across many applications, yet at the same time allows you to write code specific to each application that hosts the COM add-in.

A COM add-in is a dynamic-link library (DLL) that contains not only your custom code, but also special registry entries. These registry entries are used by Microsoft Office applications to determine the COM add-in's behavior at run time.

As its name implies, a COM add-in uses Component Object Model (COM) technology, and not managed (.NET) code. However, you can create a managed COM add-in using Visual Studio .NET; although the resulting managed COM add-in created by Visual Studio .NET is a .NET assembly with the file extension .dll and is not truly a COM DLL. However, there is enough information added by Visual Studio .NET to mimic a COM add-in at run time when loaded by Office applications. I will use the terms managed COM add-in and Shared Add-In project interchangeably throughout the rest of this month's column as I describe how to create a managed COM add-in using Visual Studio .NET.