Andy Lippitt

If an instance of a type is created locally via new, then that type is subsequently the target of a RegisterActivatedClientType, later new instances avoid the channel.

What's going on here

Is there some sort of caching taking place when the first instance is created that makes subsequent instances not check if the type is remoted Can I clear this cache or otherwise get this to work the way I want

Thanks,
Andy


Re: .NET Remoting and Runtime Serialization RegisterActivatedClientType after first local instance

Clemens Vasters - MSFT

Yes, there is caching taking place in the System.Activator infrastructure. In order to improve performance when creating instances there's a tradeoff between flexibility and speed there. It's not a common scenario to switch back and forth between local activation and remote activation and typically all registration of remote types is done upfront in code and/or config.

If you want to flip back and forth between local and remote classes (which I personally find to be a problematic architectural decision, but that's not the point here) I strongly suggest that you make this explicit by introducing a factory class that makes that decision and explicitly calls into the infrastructure beneath "new" to create the instance for you. That would also serve to circumvent the caching. In the case you are local, you'd rely on System.Activator to create instances for you and in the remote case you'd have to do a remote factory or a bit of a fun hack to get where you seem to like to be going. Ingo Rammer has a few hints and alternative approaches around that here [1] and here [2].

[1] http://www.thinktecture.com/Resources/RemotingFAQ/CAOS_WSDL.html
[2] http://www.apress.com/ApressCorporate/supplement/1/47/1590590252-442.pdf






Re: .NET Remoting and Runtime Serialization RegisterActivatedClientType after first local instance

Andy Lippitt

While I agree that designing an architecture as you describe would be a questionable choice, in fact what I'm trying to do is much more suspect ;)

I'm using remoting to intercept calls between two third party pieces of code for the purposes of logging their interaction without modification to either (precluding the Activator.GetObject() approach). My issue is that I'm uncertain of the timing of my injection into this domain and was hoping to be able to recover from an "after first call" sort of scenario.

I remember reading someplace that there is a Type cache that is separate from the MemberInfo cache. Something about weak references from the former to the latter. Any way I can convince GC to clear this cache Am I barking of the proper tree at least

Andy




Re: .NET Remoting and Runtime Serialization RegisterActivatedClientType after first local instance

Clemens Vasters - MSFT

The problem here is not that the Types are cached but the Activators for the types are cached. An activator is an internal .NET construct that acts as the class factory for a Type. The GC doesn't ever clear caches.

Since Remoting wasn't built as a general purpose interception mechanism that you can dynamically swap in and out at runtime and because there's optimization going on in realization of that fact, it'll be hard for you to build around these constraints. I think that that's not what you want to hear. To me it sounds as if you are building a debugger/profiler kind of tool and it looks as if you probably have to hook several tiers further down in the CLR to get what you want.

Here's the web search that may make sense for you to look at: http://search.live.com/results.aspx q=CLR+profiler+api






Re: .NET Remoting and Runtime Serialization RegisterActivatedClientType after first local instance

Andy Lippitt

The profiler API looks very promising.

Thank you.