[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.remoting

Can't return MarshalByRefObject from remote serviced component

Luke Stevens

7/5/2004 6:43:00 AM

I'm trying to do something really simple and keep getting this cryptic .NET Remoting error:

"This remoting proxy has no channel sink which means either the server has no registered server channels that are listening, or this application has no suitable client channel to talk to the server."

Now, I'm not even using .NET Remoting in any direct sense; I'm just trying to call a remote serviced component, letting COM+/ES do all the hard stuff. I have code like this on the server:

public sealed class Funk : ServicedComponent, IFunk
{
public ISpaz GetSpaz() { return new Spaz(); }
}

public sealed class Spaz : MarshalByRefObject, ISpaz
{
public int Work() { return 42; }
}

....and on the client, I do this:

IFunk funk = new Funk();
ISpaz spaz = funk.GetSpaz();
int x = spaz.Work(); // fails

If the client is remote, this code fails on the last line with the error quoted above. If I change Spaz to be a full-blown serviced component, everything is fine. If a change it to be marshal by value, everything is fine (though interestingly it is still marshaled by reference via a CCW). I can't do either in my real-life case because my Spaz is actually a local transparent proxy. Anyway, if I run this code within the server process, everything is fine. More strangely still, if I write a remote client in unamanged code that does *exactly the same thing*, like so:

IFunkPtr funk(__uuidof(Funk));
ISpazPtr spaz = funk->GetSpaz();
int x = spaz->Work();

....it works beautifully! Furthermore, if I park the debugger on the last line of the managed code, manually shut down the server, and run the final line, I get exactly the same error. So on the server side there is nothing amiss at all, and whatever is wrong is on the client.

So, stepping through the disassembly I find that the framework on the client receives this ISpaz objref and goes to unmarshal it into the managed world, and somehow it can tell from the objref whether the remote object is a serviced component, some other marshal-by-ref managed object, or a plain old COM object. I'm not sure what the point is of differentiating the latter two, but unfortunately, when it turns out to be a marshal-by-ref object, the framework apparently loses track of the COM channel, and the client is left holding an orphaned proxy.

Is this a bug, or is there some logic to it I'm not seeing?