Discussion:
Consuming COM Obj In A .NET Assembly From A Different .NET Assembly
(too old to reply)
Bowman, John C.
2009-04-20 21:29:10 UTC
Permalink
Hi All,

I've got an interop problem I need some help with & I'm very green at .NET
interop. Assume I have .NET A.DLL that exposes a COM object that is running
under A.EXE (also a .NET app) that has been registered using Regasm.exe. Now
assume I've got .NET B.DLL (running under .NET B.EXE) that needs to consume
the COM object exposed by A.DLL. When I set a reference in B.DLL's project
to A.DLL, that reference requires that a copy of A.DLL now be either in the
GAC (not an acceptable solution for other reasons) or in the local install
folder where B.DLL resides. This means that we have to distribute A.DLL with
application B.EXE & D.DLL - which we don't like either. If I try to set the
reference in B.DLL's project to the .TLB available from A.DLL, then VS 2005
complains I can't do that & I need to set the reference directly to the
A.DLL assembly.

I know that if A.DLL were an unmanaged .DLL that exposed a COM object, then
a simple interop assembly is created when B.DLL is compiled and that interop
assembly get's distributed. That's OK. But since A.DLL is a .NET assembly we
seem to be forced to distribute A.DLL w/ B.LL. What I'd really like is the
equivalent to the simple interop dll for A.DLL. Is there some way to do this
(manifest(s) and/or some sort of interop assembly?) where we don't have to
distribute A.DLL w/ B.DLL?

TIA,

John
Bowman, John C.
2009-04-21 11:34:41 UTC
Permalink
Hi All,

Sorry about the double post, my email client crash when I sent it and I
thought it didn't go through...

John
Post by Bowman, John C.
Hi All,
I've got an interop problem I need some help with & I'm very green at .NET
interop. Assume I have .NET A.DLL that exposes a COM object that is
running under A.EXE (also a .NET app) that has been registered using
Regasm.exe. Now assume I've got .NET B.DLL (running under .NET B.EXE) that
needs to consume the COM object exposed by A.DLL. When I set a reference
in B.DLL's project to A.DLL, that reference requires that a copy of A.DLL
now be either in the GAC (not an acceptable solution for other reasons) or
in the local install folder where B.DLL resides. This means that we have
to distribute A.DLL with application B.EXE & D.DLL - which we don't like
either. If I try to set the reference in B.DLL's project to the .TLB
available from A.DLL, then VS 2005 complains I can't do that & I need to
set the reference directly to the A.DLL assembly.
I know that if A.DLL were an unmanaged .DLL that exposed a COM object,
then a simple interop assembly is created when B.DLL is compiled and that
interop assembly get's distributed. That's OK. But since A.DLL is a .NET
assembly we seem to be forced to distribute A.DLL w/ B.LL. What I'd really
like is the equivalent to the simple interop dll for A.DLL. Is there some
way to do this (manifest(s) and/or some sort of interop assembly?) where
we don't have to distribute A.DLL w/ B.DLL?
TIA,
John
TDC
2009-04-22 12:39:27 UTC
Permalink
I had to read that twice to get what you were after, but I've got it
now.

If all you are doing is trying to expose the COM definition which is
in "A", but not the implementation which is in "A", then you need to
pull the COM definition out of "A" into another library, lets call it
"Z", and then both "A" and "B & D" reference "Z".

What I don't fully understand in your question is where COM comes into
play at all. All your components you listed you said were .NET?
Post by Bowman, John C.
Hi All,
I've got an interop problem I need some help with & I'm very green at .NET
interop. Assume I have .NET A.DLL that exposes a COM object that is running
under A.EXE (also a .NET app) that has been registered using Regasm.exe. Now
assume I've got .NET B.DLL (running under .NET B.EXE) that needs to consume
the COM object exposed by A.DLL. When I set a reference in B.DLL's project
to A.DLL, that reference requires that a copy of A.DLL now be either in the
GAC (not an acceptable solution for other reasons) or in the local install
folder where B.DLL resides. This means that we have to distribute A.DLL with
application B.EXE & D.DLL - which we don't like either. If I try to set the
reference in B.DLL's project to the .TLB available from A.DLL, then VS 2005
complains I can't do that & I need to set the reference directly to the
A.DLL assembly.
I know that if A.DLL were an unmanaged .DLL that exposed a COM object, then
a simple interop assembly is created when B.DLL is compiled and that interop
assembly get's distributed. That's OK. But since A.DLL is a .NET assembly we
seem to be forced to distribute A.DLL w/ B.LL. What I'd really like is the
equivalent to the simple interop dll for A.DLL. Is there some way to do this
(manifest(s) and/or some sort of interop assembly?) where we don't have to
distribute A.DLL w/ B.DLL?
TIA,
John
Bowman, John C.
2009-04-24 15:52:58 UTC
Permalink
Thanks for the tip TDC,

The reason COM is there in the first place is that it's an older component
that is used by several other app's. But now we need to use it in an
isolated/local fashion w/ registration free. That's where we're trying to
get too w/ this.

John

"TDC" <***@lycos.com> wrote in message news:e8553147-9f7c-46b6-b009-***@l1g2000yqk.googlegroups.com...
I had to read that twice to get what you were after, but I've got it
now.

If all you are doing is trying to expose the COM definition which is
in "A", but not the implementation which is in "A", then you need to
pull the COM definition out of "A" into another library, lets call it
"Z", and then both "A" and "B & D" reference "Z".

What I don't fully understand in your question is where COM comes into
play at all. All your components you listed you said were .NET?
Post by Bowman, John C.
Hi All,
I've got an interop problem I need some help with & I'm very green at .NET
interop. Assume I have .NET A.DLL that exposes a COM object that is running
under A.EXE (also a .NET app) that has been registered using Regasm.exe. Now
assume I've got .NET B.DLL (running under .NET B.EXE) that needs to consume
the COM object exposed by A.DLL. When I set a reference in B.DLL's project
to A.DLL, that reference requires that a copy of A.DLL now be either in the
GAC (not an acceptable solution for other reasons) or in the local install
folder where B.DLL resides. This means that we have to distribute A.DLL with
application B.EXE & D.DLL - which we don't like either. If I try to set the
reference in B.DLL's project to the .TLB available from A.DLL, then VS 2005
complains I can't do that & I need to set the reference directly to the
A.DLL assembly.
I know that if A.DLL were an unmanaged .DLL that exposed a COM object, then
a simple interop assembly is created when B.DLL is compiled and that interop
assembly get's distributed. That's OK. But since A.DLL is a .NET assembly we
seem to be forced to distribute A.DLL w/ B.LL. What I'd really like is the
equivalent to the simple interop dll for A.DLL. Is there some way to do this
(manifest(s) and/or some sort of interop assembly?) where we don't have to
distribute A.DLL w/ B.DLL?
TIA,
John
Loading...