|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
How does one disable the CrossAppDomain channel?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! Hello,
CrossAppDomainChannel is a private internal channel. All about it is not documented so that there is no a public way to disabled it. Anyway, The remoting framework uses it for cross-domain remoting purposes (within the same process). Is it possible to set up a multiple domains test environment on your test computer? Regards, Luke Zhang Microsoft Online Community Support ================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ================================================== (This posting is provided "AS IS", with no warranties, and confers no rights.) I did write my own custom channel in the past and I had no problem testing
it.... Perhaps you run all your test in the same process? I used 2 different process (on my single machine)... Show quote "Eric" <ehahn9@nospam.nospam> wrote in message news:CD65E766-B2EC-40EC-A438-75ED73029C72@microsoft.com... > 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! > Ahh, so create a separate process might do the trick? Sounds like a winner
for us. I just want to confirm that you had success avoiding the CrossAppDomain optimization across two processes on the same box? Show quote "Lloyd Dupont" wrote: > I did write my own custom channel in the past and I had no problem testing > it.... > Perhaps you run all your test in the same process? > I used 2 different process (on my single machine)... > Eric wrote:
> Ahh, so create a separate process might do the trick? Sounds like a It definitely looks like the cross app domain channel only works between app > winner for us. > > I just want to confirm that you had success avoiding the > CrossAppDomain optimization across two processes on the same box? domains in a single host process. -cd |
|||||||||||||||||||||||
Other interesting topics