Rick, I have a sample at [1] that does what you're looking to do. It uses proxies to tweak the ObjRef. I also have another sample [2] that does it by overriding CreateObjRef in MBRO. AFAIK, tweaking the TypeInfo in the ObjRef is the way to accomplish what you're after. I've never experienced the JIT problem to which you refer.
Jim [1] http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=a527f 9e3-d23f-46b8-84c1-7df6be8ed8a8 [2] http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=f2879 fcf-b794-4339-a71c-9e4f1209ffde > -----Original Message----- > From: Rick Byers [mailto:[EMAIL PROTECTED] > Sent: Monday, March 31, 2003 12:49 PM > To: [EMAIL PROTECTED] > Subject: [ADVANCED-DOTNET] Restricting a proxied type when > its concrete type is available > > > Hi, > When GetType is called on a TransparentProxy, the CLR > attempts to get the real type of the object being proxied by > calling RemotingServices.GetType(TransparentProxy), loading > assemblies as necessary. In a normal remoting scenario where > the implementation assembly is unavailable, this will fail > and GetType will return typeof(MarshalByRefObject). However, > it the CLR can find the appropriate assembly, it will load it > and return the actual Type of the object being proxied. I > don't think this is desirable in all situations. > > I've got a program that uses many AppDomains which > communicate via remoting. There is one main internal assembly > with a number of MarshalByRefObjects that implement public > interfaces in a shared assembly. I do NOT want my internal > assembly loaded into the "client" AppDomains, but the > assembly needs to be available for my "server" AppDomain. > The "client" AppDomains should only have knowledge of the > interface and should be completely detached from the > implementation of these objects. My main motivation is just > that its WRONG to have my implementation code loaded into my > client AppDomains, but there are some real problems like > memory footprint (the client AppDomains are supposed to be > light weight). > > When an object is made available via remoting, there must be > some way to specify that only one of its base types or > interfaces is to be exposed. After a lot of hunting through > the SSCLI, I decided that the "right" way to do this was to > override MarshalByRefObject.CreateObjRef(Type requestedType) > to explicitly request an ObjRef for the type I wanted to > expose (the interface my MRBO implements). Does this seem > right? I couldn't find any documentation or other discussion > about doing this, but this feels right to me based on all the > code to deal with the "requestedType" parameter (which seems > to always be null, meaning use the real type, in practice). > > Doing this causes the Remoting.TypeInfo held in the ObjRef to > only contain information about my interface, not my concrete > type. This works perfectly almost all of the time, but in > certain situations causes the JIT-compiler to generate an > InvalidCastException when storing the proxy in a variable of > the interface type. I won't go into too much detail here > because I suspect that overriding CreateObjRef to supply an > interface type might be the wrong thing to do anyway. If > this should actually work properly, then I can provide some > sample code that explores the JIT bug in more detail. Using > an abstract base class instead of an interface works fine, > but doesn't seem right because it is just an interface I want > to expose, and I may want my actual implementation to inherit > functionality from some other class. > > Does anyone know what the right way to achieve this is? Can > anyone provide me with some information on how CreateObjRef > is supposed to be overridden and what the requirements are > for ObjRefs TypeInfo object? I've read a number of books on > remoting (Ingo Rammer's Advanced .NET remoting, and the MS > Press .Net remoting book), but haven't found this level of > details anywhere. > > Thanks, > Rick >
