Re: COM component deployment question
Well, you should first think carefully if exposing it over DCOM
makes sense. It may seem a good idea at a first glance, and
then you discover all kinds of issues with that.
On the technical side, accessing a DCOM server remotely is
as simple as registering it with DCOM at the server (creating an
AppID entry) and configuring the DCOM security settings
(identity, launch and access control), then registering its proxy/
stub DLL and/or type library at each client. Optionally you can
register it with DCOM at each client as well, in case you don't
want to specify the DCOM server in CoCreateInstanceEx or
VB's CreateObject. This is done again by creating an AppID
and CLSID entries without an associated LocalServer32 entry.
The AppID specifies the machine where your server is located.
For VB's sake you may want to recreate the server's ProgIDs
at each client as well (otherwise you have to use the "clsid:xxx"
syntax in VB and it's hideous). The easiest way to recreate
all of the server's client settings for DCOM is to install the server
at a machine, remove each CLSID's LocalServer32 entry,
configure in DCOMCnfg to delegate to another computer,
and fianlly export all the settings in a text file (a registry changes
monitoring tool will come in handy if you don't know them in
advance).
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================
"abcd" <abcd@xyz.com> wrote in message
news:%23GoyUL4zGHA.4796@TK2MSFTNGP06.phx.gbl...
Brian,
I can not do any of this as the COM EXE is the third party engine we have
integrated in our product. We don't own source code. Its not a simple
component. Its made up of lots of underlying thing which is out of my
scope to trace and make another component.
thanks
"Brian Muth" <bmuth@mvps.org> wrote in message
news:%23rTnBn3zGHA.2036@TK2MSFTNGP05.phx.gbl...
Sorry, I assumed your COM object was a DLL, not an executable. This will
mean more work on your end...
Here are some choices:
- you could rewrite your executable as a DLL. Usually this is pretty
easy, by simply creating a new COM DLL using Visual Studio and
copy-pasting your logic from the original source code. Then create a COM+
application and install your DLL. Then follow the instructions in my
previous posts.
- you could write a simple COM DLL quite trivially in VB6 that calls your
remote COM executable using the CreateObject (<MyObject>,<remoteComputer)
expression. This VB6 DLL is basically acting as a proxy for the remote
COM executable. You can then use TLBIMP.EXE to create a Runtime Class
Wrapper that you can use with your .NET client.
- assuming that your COM executable is automation-compliant, you could
use TLBIMP.exe to create a Runtime Class Wrapper. Now create a .NET
object on the remote machine that can be called remotely either through
web services or .NET remoting.
Brian