views:

349

answers:

2

I have Excel add-in which I add so many class modules that it is now very bulky. I want to convert it into a type library or a COM package so that I can re-use it for the other apps in the MS Office suite.

I ported the add-in to Visual Studio as a class library project but Excel Automation doesn't recognize the classes in the compiled .dll file. Intuitively I think I would need a manifest, an interface or the something like that in my code.

What do I need to know in order to expose a class's methods and properties for use in OLE Automation?

+1  A: 

I am assuming since you used the phrase manifest, you are assembling this DLL using a .net development platform VS2003, VS2005 or VS2008 as compared to a VS 6.0

This link provides a detailed set of steps required to register a .NET assembly for use as COM component.

The one thing the article doesn't mention that I routinely do is create my own GUIDs. Use the Create GUID item in the Tools menu then insert them above the classes, interfaces, and enums you want exposed for COM.

[Guid("3838ADC1-E901-4003-BD0C-A889A7CF25A1")]
public interface IMyCOMClass  {
    void MyMethod(); 
}

[Guid("476BDEB6-B933-4ed5-8B86-7D9330A59356"),
ClassInterface(ClassInterfaceType.None)]
public class MyCOMClass : IMyCOMClass {
    public void MyMethod() { 
        //implementation here
    }
}

The second thing I do is use a separate interface for the COM portion that is implemented by the class. The reasoning for doing this has to do with the breakability of COM when the interface changes, think DLL Hell.

Hope this helps, Bill.

Bill
+1  A: 

(Assuming it's a .NET project)

Besides having to add the Guids to your interfaces and classes, you also need to mark them with the ComVisible attribute (unless you've marked the whole assembly with it). Also, you need to use the tlbexp.exe to export the metadata as a COM typelibrary for referencing in unmanaged clients.

Franci Penov