“ServicedComponentEx” broken

1 minute read

"ServicedComponentEx" broken: The code that I published a year ago here in order to fix the dependency of ServicedComponents on the default appdomain (and its config) no longer works with the Framework 1.1. The reason for that is that the cross-appdomain case of Remoting now explicitly filters calls to IRemoteDispatch and rejects them. The way the proxy attribute of my hack works is that it redirects the activation into a different AppDomain and therefore causes a "double proxy" to be created. The proxy that the ES infrastructure talks to is indeed a cross-appdomain proxy which talks to a transparent serviced component proxy in the target appdomain. If a managed call comes in from a different process, it wants to talk to IRemoteDispatch to circumvent COM/Interop (IRemoteDispatch is where the DCOM tunneled binary serializer packages get dropped in) and that call then gets forwarded into the secondary app domain through the cross-appdomain proxy.

Now, in the 1.1 Framework, any IRemoteDispatch calls through Remoting are explicitly rejected and hence the hack no longer works. Bummer. However, I did expect some things to break and this should be a reminder that any hacks in undocumented territory that you may find anywhere are not guaranteed to work in the next version, even point releases of the Framework. I am poking around to get the functionality restored, but based on what I've figured out so far it doesn't really seem possible without either violating the rules of the game in very horrible ways or moving this functionality into the core framework I built to make aspects work .... 


Leave a Comment