COM+ Interop problem

[Martin Maat]

Hi.

I am using a COM component from managed code doing the following:

Type type = Type.GetTypeFro mCLSID(new
Guid("B70FAAE6-4F85-480A-B1C5-DC9A6F175BFC"), serverMachineNa me, true);
history = Activator.Creat eInstance(type) as HistoryClass;

This works on the local machine, no problem whatsoever. But when I run the
client remotely, the cast in the second line of code shown above fails.

I do get an object, I do see the component being activated on the server,
but casting the object to the HistoryClass type (which is from a proxy dll
produced by tlbimp) does no longer result in a valid object. I either get
null if I use "as HistoryClass" as shown above or I get a runtime error
saying the cast is invalid if I use "(HistoryClass) " before Activator. So I
can't use the object, the proxy seems disfunctional.

I tried casting to the interface instead (I have an IHistory interface
implemented by the class object which is the one I need) but to no avail.

Can someone who is the greater COM Interop expert shed some light on this
please? (preferably showing me how to do it right) ?

Regards, Martin.

[Shakir Hussain]

Use

Activator.GetOb ject instead of Activator.Creat eInstance.

--
Shak
(Houston)
"Martin Maat" <du***@somewher e.nl> wrote in message
news:10******** *****@corp.supe rnews.com...

Hi.

I am using a COM component from managed code doing the following:

Type type = Type.GetTypeFro mCLSID(new
Guid("B70FAAE6-4F85-480A-B1C5-DC9A6F175BFC"), serverMachineNa me, true);
history = Activator.Creat eInstance(type) as HistoryClass;

This works on the local machine, no problem whatsoever. But when I run the
client remotely, the cast in the second line of code shown above fails.

I do get an object, I do see the component being activated on the server,
but casting the object to the HistoryClass type (which is from a proxy dll
produced by tlbimp) does no longer result in a valid object. I either get
null if I use "as HistoryClass" as shown above or I get a runtime error
saying the cast is invalid if I use "(HistoryClass) " before Activator. So I can't use the object, the proxy seems disfunctional.

I tried casting to the interface instead (I have an IHistory interface
implemented by the class object which is the one I need) but to no avail.

Can someone who is the greater COM Interop expert shed some light on this
please? (preferably showing me how to do it right) ?

Regards, Martin.

[Martin Maat]

"Shakir Hussain" <sh**@fakedomai n.com> wrote in message
news:uP******** *****@tk2msftng p13.phx.gbl...

Hi.

I am using a COM component from managed code doing the following:

Type type = Type.GetTypeFro mCLSID(new
Guid("B70FAAE6-4F85-480A-B1C5-DC9A6F175BFC"), serverMachineNa me, true);
history = Activator.Creat eInstance(type) as HistoryClass;

This works on the local machine, no problem whatsoever. But when I run the client remotely, the cast in the second line of code shown above fails.

I do get an object, I do see the component being activated on the server, but casting the object to the HistoryClass type (which is from a proxy dll produced by tlbimp) does no longer result in a valid object. I either get null if I use "as HistoryClass" as shown above or I get a runtime error
saying the cast is invalid if I use "(HistoryClass) " before Activator. So I can't use the object, the proxy seems disfunctional.

I tried casting to the interface instead (I have an IHistory interface
implemented by the class object which is the one I need) but to no avail.
Can someone who is the greater COM Interop expert shed some light on this please? (preferably showing me how to do it right) ?

Use Activator.GetOb ject instead of Activator.Creat eInstance.

I have to specify a URL with this method and after trying several I still
get nothing but error messages. The most common are:

"Invalid URL"
"No connection could be made because the target machine actively refused it"
(and this would still be the local machine)

I must say I hardly know what I am doing when specifying the URL, I read it
is mostly used to target modules that are hosted in IIS which makes sense. I
am however targeting a COM component on a remote machine, should my URL
include the friendly class name? The server module? Just the machine and a
port number? What port number? I tried both tcp:// and http:// URLs.
I then reverted to this approach:

object obj = Activator.Creat eInstance(type) ;
history = Marshal.CreateW rapperOfType(ob j, typeof(HistoryC lass)) as
IHistory;

which worked beautifully again locally, yet gave me
"Source object cannot be converted to the destination type since it does not
support all the required interfaces"
on a remote client machine.

My component is OLE automation compliant, it has dual interfaces.

For the moment both server and client machines are running Windows XP. Any
idea's would be greatly appreciated.

Regards, Martin.

[Martin Maat]

I should add that I just discovered classic COM clients not to work anymore
remotely either, giving me "Interface not supported". So the latter approach
may be just fine, I am having some old fashioned COM-trouble here.

Martin.

[Martin Maat]

"Martin Maat" <du***@somewher e.nl> wrote in message
news:10******** *****@corp.supe rnews.com...

I should add that I just discovered classic COM clients not to work anymore remotely either, giving me "Interface not supported". So the latter approach may be just fine, I am having some old fashioned COM-trouble here.

The machines were not both members of the same domain. Once I had the client
join the domain the server machine was in I had no problems anymore. I can
still log on locally on the client machine and it still works, I don't have
to be logged on to the domain on both machines. Apperently the machines just
did not trust eachother enough.

Martin.