|
|
You're in the
dotnet interop
group:Cant use a COM Component from .NET if it was exported from .NET
dotnet interop:
I have a COM server executable, written in .NET. I exported a type library
and registered it. So now I can create an instance of the component using CreateInstance from non .NET code. That works fine. I can also get hold of the instance by calling GetObject from non .NET code. So at this point I have the server running, but I also want to talk to it from .NET clients. If I try to add the the exported type library to a .NET client, I get an error that I I can't add the type library because it was exported from a .NET component and that I should add the assembly instead. So I can add the assembly as a reference. If I then call Marshall.GetActiveInstance, then I can not cast it using Marshall.CreateWrapperOfType it gives me a type mismatch error because the type is not derived from a COM object. I want to be able to talk to the already running COM server instance from another .NET application. But it wont let me because that COM instance was written in .NET!
So you can write COM components in .NET but you cant use such COM components
from .NET as COM components? Is that it? [quoted text, click to view] "Ben" wrote:
> I have a COM server executable, written in .NET. I exported a type library > and registered it. > > So now I can create an instance of the component using CreateInstance from > non .NET code. That works fine. I can also get hold of the instance by > calling GetObject from non .NET code. > > So at this point I have the server running, but I also want to talk to it > from .NET clients. > > If I try to add the the exported type library to a .NET client, I get an > error that I I can't add the type library because it was exported from a .NET > component and that I should add the assembly instead. > > So I can add the assembly as a reference. If I then call > Marshall.GetActiveInstance, then I can not cast it using > Marshall.CreateWrapperOfType it gives me a type mismatch error because the > type is not derived from a COM object. > > I want to be able to talk to the already running COM server instance from > another .NET application. But it wont let me because that COM instance was > written in .NET! >
I think that's correct, yes, you can't have a .NET client with a .NET COM
object (because you can just add the assembly reference to the client anyway). Internally there'd be a RCW talking to a CCW, and I don't believe that works. -- Phil Wilson [MVP Windows Installer] [quoted text, click to view] "Ben" <Ben@discussions.microsoft.com> wrote in message news:D887BF6A-867F-481F-85AA-03F229256325@microsoft.com... > So you can write COM components in .NET but you cant use such COM > components > from .NET as COM components? Is that it? > > "Ben" wrote: > >> I have a COM server executable, written in .NET. I exported a type >> library >> and registered it. >> >> So now I can create an instance of the component using CreateInstance >> from >> non .NET code. That works fine. I can also get hold of the instance by >> calling GetObject from non .NET code. >> >> So at this point I have the server running, but I also want to talk to it >> from .NET clients. >> >> If I try to add the the exported type library to a .NET client, I get an >> error that I I can't add the type library because it was exported from a >> .NET >> component and that I should add the assembly instead. >> >> So I can add the assembly as a reference. If I then call >> Marshall.GetActiveInstance, then I can not cast it using >> Marshall.CreateWrapperOfType it gives me a type mismatch error because >> the >> type is not derived from a COM object. >> >> I want to be able to talk to the already running COM server instance from >> another .NET application. But it wont let me because that COM instance >> was >> written in .NET! >> >> How do I get around it please?
Yes, but then you end up with a different instance of the component dont
you?!?!? In this case I want to talk to the COM instance that is already running because there is data in it. Or is there a way in .NET to get hold of that instance and talk to it the way you would talk to a .NET component? Note we also want non .NET software to be able to talk to the same instance of it, which they can only do by talking to it as a COM object by finding it
[quoted text, click to view]
"Ben" <Ben@discussions.microsoft.com> wrote in message news:D887BF6A-867F-481F-85AA-03F229256325@microsoft.com... > So you can write COM components in .NET but you cant use such COM > components > from .NET as COM components? Is that it? Yes, that's it. But why would you ever want to?, your .NET client can simply use the .NET "components" as ... .NET components. Willy.
[quoted text, click to view]
"Ben" <Ben@discussions.microsoft.com> wrote in message news:8D55E138-CCA4-463C-85C9-B5AC0A2436AC@microsoft.com... > Yes, but then you end up with a different instance of the component dont > you?!?!? > > In this case I want to talk to the COM instance that is already running > because there is data in it. > > Or is there a way in .NET to get hold of that instance and talk to it the > way you would talk to a .NET component? > > Note we also want non .NET software to be able to talk to the same > instance > of it, which they can only do by talking to it as a COM object by finding > it > in the running object table. A .NET client must call Marshal.GetActiveObject to connect to a running instance, note that YOU are responsible for registering the instance in the ROT at the server side, this is not done automatically. Anyway, this is old hat, much better and a lot easier is to use System.Enterprises and derive your class from ServicedComponent. All you need to do is tag your assembly, interface and class with the right attributes in order to run this class in a COM+ surrogate process as a pooled singleton. Attributes you need to set are JustInTimeActivation, ObjectPooling with both MinPoolSize and MinPoolSize set to 1. This way the class object becomes the one and only instance clients can connect with. Object life-time and state management can be implemented by overriding the ServicedComponent methods Activate, Deactivate, CanBePooled.... A .NET client can early bind using the metadata supplied by the interface, while COM clients can early bind using the typelib created when registering the .NET assembly with the COM+ catalog (using regsvcs.exe), there is no need for the COM client to bind to a running object, as there is only one single object of that type running, both .NET and COM clients will always connect to the same instance. Willy.
Thanks. I shall have to Google that a bit to make sure I understand it all,
but I think its the right answer. <g> [quoted text, click to view] "Willy Denoyette [MVP]" wrote:
> "Ben" <Ben@discussions.microsoft.com> wrote in message > news:8D55E138-CCA4-463C-85C9-B5AC0A2436AC@microsoft.com... > > Yes, but then you end up with a different instance of the component dont > > you?!?!? > > > > In this case I want to talk to the COM instance that is already running > > because there is data in it. > > > > Or is there a way in .NET to get hold of that instance and talk to it the > > way you would talk to a .NET component? > > > > Note we also want non .NET software to be able to talk to the same > > instance > > of it, which they can only do by talking to it as a COM object by finding > > it > > in the running object table. > > > > A .NET client must call Marshal.GetActiveObject to connect to a running > instance, note that YOU are responsible for registering the instance in the > ROT at the server side, this is not done automatically. > Anyway, this is old hat, much better and a lot easier is to use > System.Enterprises and derive your class from ServicedComponent. All you > need to do is tag your assembly, interface and class with the right > attributes in order to run this class in a COM+ surrogate process as a > pooled singleton. Attributes you need to set are JustInTimeActivation, > ObjectPooling with both MinPoolSize and MinPoolSize set to 1. > This way the class object becomes the one and only instance clients can > connect with. Object life-time and state management can be implemented by > overriding the ServicedComponent methods Activate, Deactivate, > CanBePooled.... > A .NET client can early bind using the metadata supplied by the interface, > while COM clients can early bind using the typelib created when registering > the .NET assembly with the COM+ catalog (using regsvcs.exe), there is no > need for the COM client to bind to a running object, as there is only one > single object of that type running, both .NET and COM clients will always > connect to the same instance. > > Willy. > > > >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |