rsioson
May 29th, 2002, 02:36 PM
After some mind-boggling hours reviewing all sorts of documentation, I've got some first steps that we can play with and hopefully people can correct and adjust where I've gone wrong. For now take my word for it, because it works for me:
CODE REQUIREMENTS:
1. On the Solution Property Pages, under "Configuration Properties", the "Build" options have a checkbox for "Register for COM Interop". Check this item. Ensure that it's checked for Release builds.
2. Every public Class should have the line
<ClassInterface(ClassInterfaceType.AutoDual), IDispatchImpl(IDispatchImplType.CompatibleImpl)> _
prior to every public Class declaration. No, I'm not convinced that both attributes are necessary, so if they're not, feel free to post. I'm sure there's a way to define it just once for an entire Module, but I haven't bothered looking it up. In order for these attributes to be valid, you should have the line
Imports System.Runtime.InteropServices
at the top of the module.
3. I'm not sure of this, but according to MSDN, "COM classes must have a parameterless Public Sub New() constructor, or the class will not register correctly":
Public Sub New()
MyBase.new()
End Sub
4. Build a Solution. A DLL (or several, depending on whether or not you had any references) is placed in the bin directory of your project.
CLIENT MACHINE REQUIREMENTS:
1. The .NET Framework has to be installed on the client. You can get the dotnetfx.exe installer from Microsoft. Look up ".NET Framework Deployment" for details.
2. The .NET DLL should be placed in the same directory as the COM consumer program, eg. if you've built a DLL for MSWord, put the DLL in the same directory as the MSWord executable. I'm guessing that this is necessary since the registry has no record of where your DLL resides, even after registering it. If you look at the registry, the InProcServer32 path for your DLL is to the Common Language Runtime component (MSCOREE.DLL).
3. Ensure that other Interop components are placed in the same directory. If the DLL has references to other components, other DLL files could get created in the form of Interop.XXXX.DLL, where XXXX is the name of the component being referenced. These will be needed on the client machine.
4. Register the DLL using the "regasm" program (which resides in the Framework folder on the client) with the "/tlb" option. This will register the DLL, and create and register the type library as well.
... and I think that's it. You should be able to do whatever you need to do to create a working COM object:
Set obj = CreateObject( "MyObject.MyClass" )
var obj = new ActiveXObject( "MyObject.MyClass" );
my $obj = Win32::OLE->new( "MyObject.MyClass" );
If anyone has a dispute or clarification to the steps above, please feel free to post a reply; it would be nice to refine this procedure for those of us who need OLE development with Studio .NET.
CODE REQUIREMENTS:
1. On the Solution Property Pages, under "Configuration Properties", the "Build" options have a checkbox for "Register for COM Interop". Check this item. Ensure that it's checked for Release builds.
2. Every public Class should have the line
<ClassInterface(ClassInterfaceType.AutoDual), IDispatchImpl(IDispatchImplType.CompatibleImpl)> _
prior to every public Class declaration. No, I'm not convinced that both attributes are necessary, so if they're not, feel free to post. I'm sure there's a way to define it just once for an entire Module, but I haven't bothered looking it up. In order for these attributes to be valid, you should have the line
Imports System.Runtime.InteropServices
at the top of the module.
3. I'm not sure of this, but according to MSDN, "COM classes must have a parameterless Public Sub New() constructor, or the class will not register correctly":
Public Sub New()
MyBase.new()
End Sub
4. Build a Solution. A DLL (or several, depending on whether or not you had any references) is placed in the bin directory of your project.
CLIENT MACHINE REQUIREMENTS:
1. The .NET Framework has to be installed on the client. You can get the dotnetfx.exe installer from Microsoft. Look up ".NET Framework Deployment" for details.
2. The .NET DLL should be placed in the same directory as the COM consumer program, eg. if you've built a DLL for MSWord, put the DLL in the same directory as the MSWord executable. I'm guessing that this is necessary since the registry has no record of where your DLL resides, even after registering it. If you look at the registry, the InProcServer32 path for your DLL is to the Common Language Runtime component (MSCOREE.DLL).
3. Ensure that other Interop components are placed in the same directory. If the DLL has references to other components, other DLL files could get created in the form of Interop.XXXX.DLL, where XXXX is the name of the component being referenced. These will be needed on the client machine.
4. Register the DLL using the "regasm" program (which resides in the Framework folder on the client) with the "/tlb" option. This will register the DLL, and create and register the type library as well.
... and I think that's it. You should be able to do whatever you need to do to create a working COM object:
Set obj = CreateObject( "MyObject.MyClass" )
var obj = new ActiveXObject( "MyObject.MyClass" );
my $obj = Win32::OLE->new( "MyObject.MyClass" );
If anyone has a dispute or clarification to the steps above, please feel free to post a reply; it would be nice to refine this procedure for those of us who need OLE development with Studio .NET.