Is there a way to get a direct reference to the Assembly object in the AppDomainContext? about appdomaintoolkit HOT 2 CLOSED

You'll never be able to reference the assembly object directly from the parent domain. If you do, then you'll pollute the parent domain with that assembly—the .NET runtime will pull the assembly into whatever domain attempts to access it. Oddly this seems to happen even cross-AppDomain. What pieces of information do you need from it?

You're going to have to architect your solution such that you can interact with the target assemblies through intermediaries. That’s the whole point of the IAssemblyTarget interface—to give you information about the assembly. Are you trying to execute code from that assembly in the remote domain? If so then you should take a look at the WinBert project, specifically the RandoopTestManager (https://github.com/jduv/WinBert/blob/master/Arktos.WinBert/RandoopIntegration/RandoopTestManager.cs#L83). In this class, I execute a whole bunch of methods in a remote domain using two binaries that I have instrumented myself. The RandoopTestRunner (https://github.com/jduv/WinBert/blob/master/Arktos.WinBert/RandoopIntegration/RandoopTestRunner.cs) class is responsible for executing the methods as required. It's not a remote project (serializable or extends MarshalObjectByRef) because it completes its work and is done--it doesn't ship information back to the parent domain.

It might take a whole lot more work, but maybe you could prepare interfaces for your dynamically built assemblies and interact with them via remote objects--assuming that is what you’re trying to do of course :).

from appdomaintoolkit.

That is actually perfect. I was looking through your code and it doesn't seem like it would be hard to reconstruct my class using the IAssemblyTarget.

My application is loading custom-built plugins (which is just a collection of C# methods), generating NHibernate mapping code for these plugins, and compiling and loading that mapping code to be used by NHibernate to persist the plugin metadata to the database. This requires me to scan and load the plugin assembly (.dll or .exe provided by the user), then generate+compile+load the mapping classes for the plugin, all in a separate dedicated AppDomain - one AppDomain per plugin. The code in the plugin will be executed by the main application as requested by the user.

So I'm using your AppDomainContext in 2 ways:

1. To examine a plugin or mapping assembly by loading it dynamically, such that the AppDomain in which the assembly is loaded will not need to be known. This is implemented as a class called AssemblyExaminer which contains an instance of AppDomainContext.
2. To load plugin code that is to be executed in a separate AppDomain. This code will be executed by the main app. This is implemented by creating an instance of the AppDomainContext in my domain layer and handling it manually (which is what I was referring to when I asked about disposing the AppDomainContext). I do need information to be returned to the parent domain though, so I don't know if the RandoopTestRunner will work but I will take a look at that.

I think I can just implement another IAssemblyTarget and get whatever information I need from the underlying assembly during the FromAssembly/FromPath methods while adding whatever property holders I need. Once you said that you cannot directly access the other assembly from the current assembly, it all started making sense to me as to why we need proxy objects. I found the link to this project from StackOverflow and I think most of the answers there miss this point. Thanks for the help and once I get this working I may add some features to the project. I will probably be back for more help :)

from appdomaintoolkit.