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?
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.
(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.
Related
Has anybody tried to use C++/winrt to create Win32 COM objects? The C++/winrt docs document that consuming them is possible and of course creating "new" UWP COM objects. I was wondering if for some simple scenario's one could use the C++/winrt headers instead of ATL to generate some simple COM objects.
You can write a COM component with C++/WinRT. Here’s an example of a COM executable server but the principles and techniques are much the same for a DLL.
https://gist.github.com/kennykerr/d983767262118ae0366ef1ec282e428a
For a DLL you just want to make sure you export an implementation of DllGetClassObject and DllCanUnloadNow. Otherwise, its just like any other DLL and you can use the winrt::implements class template to implement the various classes and factories.
I have a VB6 DLL project that exposes a number of classes as COM objects to projects that reference the DLL.
I also have several functions in a BAS module. Is there any way to expose these static functions to projects that reference the DLL? I created a test project. It can access the classes but not the static functions, even though they are marked as public.
Is this even possible? Or can I only expose classes?
If you copy the code to a new class & set that classes instancing property to GlobalMultiUse in the designer then any public members of that class get added to the global namespace so you can use ProjectName.XXX.
This works fine in calls between VB6/VBA but for other callers you will need to create an instance of that class.
I'd like to have a managed com object that exposes methods which accept as arguments objects implementing given interfaces. Something like this
[ComVisible(true)]
[Guid(".....")]
class SomeClass {
public void SomeMethod(ISomeInterface arg)
.....
Apparently ISomeInterface should also be declared ComVisible.
Now I want to consume that COM object in a managed client and call SomeMethod there. The problem is I need to instantiate an object that implements ISomeInterface. If that was a native COM object I'd get an interop assembly generated automatically and that won't be a problem. One cannot generate an interop assembly for managed COM object though.
I see that .NET 4.0 introduces the type equivalence concept. It looks like I could generate an interop manually using the ComImport attribute. But that looks like a pretty nasty job. I guess I could also use the TypeIdentifierAttribute but the documentation on that is vague and it says it's mostly intended for use by compilers.
So are there any other ways to do that?
I have several ATL COM services and would like each of them to have their own namespace, but be under a single base namespace, just like the System namespace in .NET.
For example if a C# project were to include these COM objects, all would be under the same base namespace:
using MyCompanyName.Terminator;
using MyCompanyName.Superman;
using MyCompanyName.Thor;
... instead, what I have currently is this:
using Terminator;
using Superman;
using Thor;
... which is what I do NOT want. I want to be able have a base namespace and sub-namespaces under that base. I don't know how to do this when creating an ATL service and what I need to modify to do this. Is it something I modify in the IDL file?
In case you are targeting managed clients it is possible to provide namespaces for them! However since COM is language independent you cannot provide namespaces using the interface description (type library). But whenever you are creating managed wrapper assemblies (that are actually referenced by the client), they can have namespaces to address the RCW objects. The keyword you are looking for is Primary Interop Assemblies. Those are assemblies that you as the vendor of the original library provide for clients to reference. To simplify this: You are doing the work, Visual Studio does for you when you are adding a reference to a COM library. You are creating the interop assembly and the customer does not reference the type library, but the assembly you generated. Using the tlbimp.exe tool it is possible to encapsulate the RCW types inside a namespace using the /namespace parameter.
I've run across some VB.NET code that explicitly creates three GUID constants and uses them in a class's ComClass attribute. I've written COM-aware classes in the past just by checking the "Make COM-Visible" and "Register for COM interop" options in the project options. Is this explicit code simply unnecessary, or is it doing something above-and-beyond what those two options do? Here's a snippet:
<ComClass(MenuHandler.ClassId, MenuHandler.InterfaceId, MenuHandler.EventsId)> _
Public Class MenuHandler
Public Const ClassId As String = "A2204623-A902-44d4-B524-FDFFCD176E53"
Public Const InterfaceId As String = "3449CA8B-16DF-4a61-8BAB-DFF27AE70F5E"
Public Const EventsId As String = "06C156DD-0ABA-437e-9EE0-C1CE2CA34033"
End Class
The ComClass attribute is specific to Visual Basic and is intended to simplify the creation of COM objects in .Net code. When the compiler sees this attribute it do some of the tedious work under the hood that must be manually done in C#. In summary, it's a shortcut for Visual Basic Code for creating COM objects.
Here's a great article on what this provides over doing the same in C#:
http://codebetter.com/blogs/peter.van.ooijen/archive/2005/08/02/130157.aspx
By explicitly putting attributes on the classes and enumerations that you want exposed you can prevent things like helper classes, internal tools, or internal classes that should not be exposed from being exposed. This is the recommended way from Microsoft to do it...and when they recommend something, it usually means that if you don't do it, your program may break in the future. :)
Checking "make COM visible" and "register for COM interop" is the simple method for making COM visible objects, but is not recommended. This will add the overhead for every class visible - even ones that you may not want.
Will VB.NET automatically generate ComClass attribute and guids?
Yes, if you use VB.NET COMClass template to create a class, COMClassAttribute and those GUIDs will be automatically generated.
Detail in MSDN
Section "To create a COM object by using the COM class template"