.Net - Load Type dynamically from AppDomain without remoting proxy

0
votes

I've loaded a specific AppDomain up and I want to load some types dynamically from it (piece of cake right?). The thing is all of the CreateInstance methods of the AppDomain class return things as a remoting object handle. Remoting proxies have limitations that I would like to avoid such as: having to have serializable concrete classes, and over eager garbage collection unless LifeTimeService is used.

My Question is how can I load a type in another app domain without having it wrapped in a remoting proxy? Below is a snippet of my code.

AppDomainSetup ads = new AppDomainSetup();
ads.ApplicationBase = Path.GetDirectoryName(_bllAssemblyPath);
ads.PrivateBinPath =  Path.GetDirectoryName(_bllAssemblyPath);
if (File.Exists(_bllAssemblyPath + ".config"))
    ads.ConfigurationFile = _bllAssemblyPath + ".config";
_workerSpace= AppDomain.CreateDomain("worker", new System.Security.Policy.Evidence(AppDomain.CurrentDomain.Evidence), ads );

_bllQueue = _workerSpace.CreateInstanceFrom(_bllAssemblyPath, queueType) as IThumbCapQueue;
2
.netremotingappdomaindynamic-loading
I don't think you can do that. What is it you're trying to do that requires you create the object in a separate AppDomain? – Jonathan Rupp
I'm building a Windows Service and i'd like _bllQueue to be hosted in a separate memory space from the main service memory space. – James

2 Answers

1
votes

You will always need some type of proxy to talk between app domains as .NET won't let you directly access the memory of objects in another app domain. Also note that both AppDomains in your example will run within the same Windows Process.

There is a new infrastructure for remoting: RIA Services that might give you the features you want.

0
votes

Instead of making the objects you are interested in remotable, make a remotable "bootstrapper" that serves as a communication channel to the remote AppDomain, and use it to load up what you're interested in. I'm doing this on a project that requires reflecting arbitrary .NET dlls to get type information from them (I do it in a new AppDomain because when I'm done I want to unload the assembly so the file's not locked) - the remoting shim loads the assembly, does reflection, gathers the necessary information and sends it back to the calling AppDomain in the form of serializable objects. See here.