G
Guest
Anyone writing a custom channel (which we have), needs to be able to disable
the CrossAppDomain channel if they want to unit test their code on a single
machine. If you don’t disable the CrossAppDomain channel, then it will take
over same-machine remoting calls (after activation) effectively making
same-machine unit testing of custom channels impossible.
More detail (if needed):
Via remoting, any machine can instance a remote object (a client activated
object (CAO), for example), just by passing a suitable URI and System.Type to
Activator. The remoting framework will package up an activation request and
send it through any channels which respond to that URI. The remote node will
receive the activation request, instance a local object, and return an
instance handle back to the caller who will create a proxy object, etc. This
is all vanilla channel stuff.
HOWEVER, as a special (cool!) optimization, if the resulting object ended up
being created on the same computer as the caller, then all subsequent
references (e.g. to the object’s methods), are diverted away from the
original channel to a special, hidden, internal CrossAppDomainChannel
(XAPPDMN) which services future requests far more efficiently than any
“normal†channel does.
The bad news comes when you actually want to *force* traffic through your
own channel. Beyond the initial activation round-trip, you cannot. This
makes same-machine unit testing impossible.
What we are looking for then is a way to teach our test framework how to
“disable†XAPPDMN from intercepting subsequent calls on the same box. We
have complete control of the URIs, the ChannelServices, even the remoting
Message properties and TransportHeaders etc. etc., but for the life of us,
cannot figure out how to do this.
Any help would be hugely appreciated!
the CrossAppDomain channel if they want to unit test their code on a single
machine. If you don’t disable the CrossAppDomain channel, then it will take
over same-machine remoting calls (after activation) effectively making
same-machine unit testing of custom channels impossible.
More detail (if needed):
Via remoting, any machine can instance a remote object (a client activated
object (CAO), for example), just by passing a suitable URI and System.Type to
Activator. The remoting framework will package up an activation request and
send it through any channels which respond to that URI. The remote node will
receive the activation request, instance a local object, and return an
instance handle back to the caller who will create a proxy object, etc. This
is all vanilla channel stuff.
HOWEVER, as a special (cool!) optimization, if the resulting object ended up
being created on the same computer as the caller, then all subsequent
references (e.g. to the object’s methods), are diverted away from the
original channel to a special, hidden, internal CrossAppDomainChannel
(XAPPDMN) which services future requests far more efficiently than any
“normal†channel does.
The bad news comes when you actually want to *force* traffic through your
own channel. Beyond the initial activation round-trip, you cannot. This
makes same-machine unit testing impossible.
What we are looking for then is a way to teach our test framework how to
“disable†XAPPDMN from intercepting subsequent calls on the same box. We
have complete control of the URIs, the ChannelServices, even the remoting
Message properties and TransportHeaders etc. etc., but for the life of us,
cannot figure out how to do this.
Any help would be hugely appreciated!