If you're using a Setup and Deployment project, if you include the DLL in
your setup project you can give it the option to register your COM object.
Do this by opening highlighting the desired DLL, and looking at its property
page. There is a "Register" property, and you can set this to one of the
following:
vsdraDoNotRegister
vsdraCOMRelativePath
vsdraCOM
If you're testing this on the same machine as your development machine, you
might want to remove the option of automatically registering the object for
COM, for it might interfere with the setup project's registration of the
object, and confuse you as to which object is actually getting registered,
and where it resides.
Hope this helps.
Levi
> Hello,
>
[quoted text clipped - 8 lines]
>
> Randy
Randy - 29 Oct 2003 03:47 GMT
Thanks for the reply.
For what ever reason this didn't work, but I was able to figure it out.
What I had to do was make sure I was deploying the .tlb file and both
the dll and tlb files have to be set to vsdrfCOM.
In my case if I did not register the tlb file then I could not see the
dll in the references dialog. Mabye I still could have done a create
object, I don't know.
Thanks again
Randy
> If you're using a Setup and Deployment project, if you include the DLL in
> your setup project you can give it the option to register your COM object.
[quoted text clipped - 28 lines]
> >
> > Randy
Levi Wilson - 30 Oct 2003 14:42 GMT
I'm pretty certain the only purpose of the tlb file is to expose your types
to your C++ code by using the #import directive. This will automatically
generate a .tlh file that the compiler will use to know how to utilize your
dll. When I registered my .NET DLL for COM, I used the COMRelativePath I
believe...well, as long as you got it working though.
> Thanks for the reply.
>
[quoted text clipped - 43 lines]
> > >
> > > Randy