We Keep Coding

AppDomain Assembly not found when loaded from byte array

Please bear with me, I spent 30+ hours trying to get this work - but without success.
At the start of my program I load an Assembly (dll) in bytearray and delete it afterwards.
_myBytes = File.ReadAllBytes(#"D:\Projects\AppDomainTest\plugin.dll");
Later on in the program I create a new Appdomain, load the byte array and enumerate the types.
var domain = AppDomain.CreateDomain("plugintest", null, null, null, false);
domain.Load(_myBytes);
foreach (var ass in domain.GetAssemblies())
{
Console.WriteLine($"ass.FullName: {ass.FullName}");
Console.WriteLine(string.Join(Environment.NewLine, ass.GetTypes().ToList()));
}
The types get correctly listed:
ass.FullName: plugin, Version=1.0.0.0, Culture=neutral,PublicKeyToken=null
...
Plugins.Test
...
Now I want to create an instance of that type in the new AppDomain
domain.CreateInstance("plugin", "Plugins.Test");
This call results in System.IO.FileNotFoundException and I don't know why.
When I look in ProcessExplorer under .NET Assemblies -> Appdomain: plugintest I see that the assembly is loaded correctly in the new appdomain.
I suspect the exception to occur because the assembly is searched again on disk. But why does the program want to load it again?
How can I create an instance in a new appdomain with an assembly loaded from byte array?

The main problem here is thinking that you can instantiate a plugin while executing code in your primary appdomain.
What you need to do instead, is create a proxy type which is defined in an already loaded assembly, but instantiated in the new appdomain. You can not pass types across app domain boundaries without the type's assembly being loaded in both appdomains. For instance, if you want to enumerate the types and print to console as you do above, you should do so from code which is executing in the new app domain, not from code that is executing in the current app domain.
So, lets create our plugin proxy, this will exist in your primary assembly and will be responsible for executing all plugin related code:
// Mark as MarshalByRefObject allows method calls to be proxied across app-domain boundaries
public class PluginRunner : MarshalByRefObject
{
// make sure that we're loading the assembly into the correct app domain.
public void LoadAssembly(byte[] byteArr)
{
Assembly.Load(byteArr);
}
// be careful here, only types from currently loaded assemblies can be passed as parameters / return value.
// also, all parameters / return values from this object must be marked [Serializable]
public string CreateAndExecutePluginResult(string assemblyQualifiedTypeName)
{
var domain = AppDomain.CurrentDomain;
// we use this overload of GetType which allows us to pass in a custom AssemblyResolve function
// this allows us to get a Type reference without searching the disk for an assembly.
var pluginType = Type.GetType(
assemblyQualifiedTypeName,
(name) => domain.GetAssemblies().Where(a => a.FullName == name.FullName).FirstOrDefault(),
null,
true);
dynamic plugin = Activator.CreateInstance(pluginType);
// do whatever you want here with the instantiated plugin
string result = plugin.RunTest();
// remember, you can only return types which are already loaded in the primary app domain and can be serialized.
return result;
}
}
A few key points in the comments above I will reiterate here:
You must inherit from MarshalByRefObject, this means that the calls to this object can be proxied across app-domain boundaries using remoting.
When passing data to or from the proxy class, the data must be marked [Serializable] and also must be in a type which is in the currently loaded assembly. If you need your plugin to return some specific object to you, say PluginResultModel then you should define this class in a shared assembly which is loaded by both assemblies/appdomains.
Must pass an assembly qualified type name to CreateAndExecutePluginResult in its current state, but it would be possible to remove this requirement by iterating the assemblies and types yourself and removing the call to Type.GetType.
Next, you need to create the domain and run the proxy:
static void Main(string[] args)
{
var bytes = File.ReadAllBytes(#"...filepath...");
var domain = AppDomain.CreateDomain("plugintest", null, null, null, false);
var proxy = (PluginRunner)domain.CreateInstanceAndUnwrap(typeof(PluginRunner).Assembly.FullName, typeof(PluginRunner).FullName);
proxy.LoadAssembly(bytes);
proxy.CreateAndExecutePluginResult("TestPlugin.Class1, TestPlugin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null");
}
Going to say this again because it's super important and I didn't understand this for a long time: when you're executing a method on this proxy class, such as proxy.LoadAssembly this is actually being serialized into a string and being passed to the new app domain to be executed. This is not a normal function call and you need to be very careful what you pass to/from these methods.

This call results in System.IO.FileNotFoundException and I don't know why. I suspect the exception to occur because the assembly is searched again on disk. But why does the program want to load it again?
The key here is understanding loader contexts, there's an excellent article on MSDN:
Think of loader contexts as logical buckets within an application domain that hold assemblies. Depending on how the assemblies were being loaded, they fall into one of three loader contexts.
Load context
LoadFrom context
Neither context
Loading from byte[] places the assembly in the Neither context.
As for the Neither context, assemblies in this context cannot be bound to, unless the application subscribes to the AssemblyResolve event. This context should generally be avoided.
In the code below we use the AssemblyResolve event to load the assembly in the Load context, enabling us to bind to it.
How can I create an instance in a new appdomain with an assembly loaded from byte array?
Note this is merely a proof of concept, exploring the nuts and bolts of loader contexts. The advised approach is to use a proxy as described by #caesay and further commented upon by Suzanne Cook in this article.
Here's an implementation that doesn't keep a reference to the instance (analogous to fire-and-forget).
First, our plugin:
Test.cs
namespace Plugins
{
public class Test
{
public Test()
{
Console.WriteLine($"Hello from {AppDomain.CurrentDomain.FriendlyName}.");
}
}
}
Next, in a new ConsoleApp, our plugin loader:
PluginLoader.cs
[Serializable]
class PluginLoader
{
private readonly byte[] _myBytes;
private readonly AppDomain _newDomain;
public PluginLoader(byte[] rawAssembly)
{
_myBytes = rawAssembly;
_newDomain = AppDomain.CreateDomain("New Domain");
_newDomain.AssemblyResolve += new ResolveEventHandler(MyResolver);
}
public void Test()
{
_newDomain.CreateInstance("plugin", "Plugins.Test");
}
private Assembly MyResolver(object sender, ResolveEventArgs args)
{
AppDomain domain = (AppDomain)sender;
Assembly asm = domain.Load(_myBytes);
return asm;
}
}
Program.cs
class Program
{
static void Main(string[] args)
{
byte[] rawAssembly = File.ReadAllBytes(#"D:\Projects\AppDomainTest\plugin.dll");
PluginLoader plugin = new PluginLoader(rawAssembly);
// Output:
// Hello from New Domain
plugin.Test();
// Output:
// Assembly: mscorlib
// Assembly: ConsoleApp
foreach (var asm in AppDomain.CurrentDomain.GetAssemblies())
{
Console.WriteLine($"Assembly: {asm.GetName().Name}");
}
Console.ReadKey();
}
}
The output shows CreateInstance("plugin", "Plugins.Test") is successfully called from the default app domain, although it has no knowledge of the plugin assembly.

Have you tried providing the Assemblies full name, In your case
domain.CreateInstance("plugin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null", "Plugins.Test");

Way to embed/reference another DLL assembly while invoking a method using C# Reflection

Is there anyway to invoke methods using C# Reflection with embedded/reference dlls?
For example consider the following senario.
I have a assembly call User.dll, which have the class as bellow
namespace User
{
public class UserInfo
{
public static string Name = "Username";
}
}
Using the above dll as reference, I can able to compile the following code and access UserInfo.Name variable.
using User;
using System.Windows.Forms;
public class Test
{
public Test()
{
MessageBox.Show("Name : " + UserInfo.Name);
}
}
Consider the above code is in another dll called Test.dll assembly. Using Assembly.LoadFile("Test.dll") and C# Reflection, when I try to invoke the Constructor, getting File not found runtime error.
Error
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.FileNotFoundException: Could not load file or assembly 'DynamicAssembly, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
at Test..ctor()
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.ConstructorInfo.Invoke(Object[] parameters)

Assembly.LoadFile method only loads the specified file. You need to use Assembly.LoadFrom method in your case. Please check for differences between Assembly.LoadFile and Assembly.LoadFrom
LoadFrom() goes through Fusion and can be redirected to another assembly at a different path but with that same identity if one is already loaded in the LoadFrom context.
LoadFile() doesn't bind through Fusion at all - the loader just goes ahead and loads exactly* what the caller requested. It doesn't use either the Load or the LoadFrom context.
Your executing code sample would be like
static void Main(string[] args)
{
var fileName = ""; //put here test.dll path
Assembly ass = Assembly.LoadFrom(fileName);
var type = ass.GetType("Test.Test");
var test = Activator.CreateInstance(type);
}

I had the same problem.
I just copied the DLL into bin folder of the project.

Using reflection to instantiate a class from an external assembly

I am currently trying to develop a method of running test classes in external projects programmatically using reflection. Here is a simplified chunk of code that should showcase my problem.
string pathToDLL = #"C:\Path\To\Test\Project\UnitTests.dll";
IEnumerable<Type> testClasses = assembly.GetExportedTypes();
Type testClass = testClasses.First();
object testClassInstance = assembly.CreateInstance(testClass.FullName);
This code throws the following exception:
'assembly.CreateInstance(testClass.FullName)' threw an exception of type 'System.Reflection.TargetInvocationException'
Data: {System.Collections.ListDictionaryInternal}
HResult: -2146232828
HelpLink: null
InnerException: {System.IO.FileNotFoundException: Could not load file or assembly 'Project.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.
File name: 'Project.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
at Project.UnitTests.TestClass..ctor()}
Message: "Exception has been thrown by the target of an invocation."
Source: "System.Private.CoreLib"
StackTrace: " at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)\r\n at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)\r\n at System.Activator.CreateInstance(Type type, Boolean nonPublic)\r\n at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, StackCrawlMark& stackMark)\r\n at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)\r\n at System.Reflection.Assembly.CreateInstance(String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)\r\n at System.Reflection.Assembly.CreateInstance(String typeName)"
In the stack trace it states that it "Could not load file or assembly 'Project.Core...'".
This project is one that the target DLL references directly (one that it tests). Does anyone know why this won't be able to pick up these DLLs automatically?
I've investigated ways of solving this problem:
It could be the way that the dlls have been compiled - this can be changed as I am in control of this - which is currently by running dotnet build */*/project.json at solution level. This successfully compiles everything, and all of the relevant DLLs seem to be populated in the bin folder. I've also investigated whether or not changing to dotnet publish or dotnet build */*/project.json --configuration Release though neither seem to have helped.
I've also looked into using different methods of compilation like Activator.CreateInstance again no dice.
I don't seem to see a way to load multiple DLLs into the same Assembly class so that I can control the references. Since AppDomains have been removed from .NET Core this doesn't look like it is possible, though I may be mistaken/looking in the wrong area.
If what I'm doing doesn't seem like it will be possible, does anyone know if this kind of functionality can be achieved using a different method? I.e. Roslyn?

I just thought that I would update this question with the solution that I managed to find, just in case someone else was having the same problem as I was. Though I would like to thank #Emrah Süngü for pointing me in the right direction.
Emrah drew my attention to the fact that I needed to import the dependencies of the DLL that I wanted to load in order to invoke the classes stored within it. One way to do this is to extend your app.config in order to import those dependencies - however I wanted to do this at runtime (with projects that I didn't know I was going to run prior starting the program) so I needed to look for another solution.
If you aren't using .NET Core this is relatively simple since AppDomains can be used to load all of the dependencies and execute your code. However, since this has been removed from .NET Core I needed to find another solution that would be compatible.
I toyed with the idea of running a separate process (or Powershell), and changing the working directory so that the process was running in the directory that stored all of the dependencies it needed. However, I couldn't find a way of doing this that allowed me to react to the outcome of running the methods.
Later I investigated manipulating the AssemblyLoadContext class, but (at the time of writing) there is little to no documentation on how this class. I did find this answer which was able to helped significantly... https://stackoverflow.com/a/37896162/6012159
In order for it to work I did have to make a slight change, instead of creating a new AssemblyLoader every time (which would cause exceptions to be thrown when trying to invoke methods within the Assembly), I reused the AssemblyLoader each time (Which removed this problem).
public class AssemblyLoader : AssemblyLoadContext
{
private string folderPath;
public AssemblyLoader(string folderPath)
{
this.folderPath = folderPath;
}
protected override Assembly Load(AssemblyName assemblyName)
{
var deps = DependencyContext.Default;
var res = deps.CompileLibraries.Where(d => d.Name.Contains(assemblyName.Name)).ToList();
if (res.Count > 0)
{
return Assembly.Load(new AssemblyName(res.First().Name));
}
else
{
var apiApplicationFileInfo = new FileInfo($"{folderPath}{Path.DirectorySeparatorChar}{assemblyName.Name}.dll");
if (File.Exists(apiApplicationFileInfo.FullName))
{
return this.LoadFromAssemblyPath(apiApplicationFileInfo.FullName);
}
}
return Assembly.Load(assemblyName);
}
}
Which can be use to load assemblies like this:
string directory = #"C:\Path\To\Project\bin\Debug\netcoreapp1.0\publish\";
string pathToDLL = #"C:\Path\To\Project\bin\Debug\netcoreapp1.0\publish\project.dll";
AssemblyLoader al = new AssemblyLoader(directory);
Assembly assembly = al.LoadFromAssemblyPath(pathToDLL);

I am assuming that "UnitTests.dll" depends on (references) other dll(s) and your program does not know where to look for those referenced dll(s). You should (in fact have to) tell it to where to look for those dll(s) as well. By default is the same directory as your EXE. You can use app.config for telling where else to look. For Load() to succeed dependant dll(s) must be stored in your app's probing path.
That is the reason why you are getting an error.
Here you can find related article.
https://msdn.microsoft.com/en-us/library/823z9h8w.aspx

Invoking remote methods is loading the remote assembly in parent appdomain

I think I've determined that even though I'm loading assemblies in a MarshalByRefObject in a new AppDomain that the assemblies are also getting loaded into the parent domain.
Here's my Assembly structure (arrows indicate dependency):
MainAssembly -> CommonInterfaceAssembly <- ExtensionAssembly
In the parent AppDomain I'm doing this:
var loader = (ExtensionLoader)extDomain.CreateInstanceAndUnwrap (Assembly.GetExecutingAssembly().FullName, "ExtensionLoader");
loader.loadExtensions (this);
and the Loader class is:
class ExtensionLoader : MarshalByRefObject
{
public List<IExtension> loadExtensions (ExtensionMgr mgr)
{
// Delegate to Addins to return the list of extensions
AddinManager.Initialize ();
AddinManager.Registry.Update ();
AddinManager.GetExtensionObjects<IExtension> ();
var extensions = new List<IExtension> (AddinManager.GetExtensionObjects<IExtension> ());
foreach (var ext in extensions) {
ext.Initialize (mgr);
}
return extensions;
}
}
I don't know if it's relevant to the question, but I am using Mono.Addins to load the extensions in the new AppDomain so I've left that code in. From what I can tell though things work fine up to the point where I invoke the Initialize method on each of the extensions.
So I have ran this scenario with the ExtensionAssembly in the same directory as the main executable and in a separate 'extensions' directory. What's curious to me is that when I invoke ext.Initialize either the ExtensionAssembly gets loaded in the parent AppDomain (if it exists in the same directory), or I get the below stack trace if not. Any ideas why?
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg, System.Exception& exc, System.Object[]& out_args) [0x001f0] in /home/tim/tmp/mono-2.10.8/mcs/class/corlib/System.Runtime.Remoting.Proxies/RealProxy.cs:247
Exception rethrown at [1]:
---> System.IO.FileNotFoundException: Could not load file or assembly 'Extensions, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
File name: 'Extensions, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
at System.AppDomain.Load (System.String assemblyString, System.Security.Policy.Evidence assemblySecurity, Boolean refonly) [0x00047] in /home/tim/tmp/mono-2.10.8/mcs/class/corlib/System/AppDomain.cs:785
at System.AppDomain.Load (System.String assemblyString) [0x00000] in /home/tim/tmp/mono-2.10.8/mcs/class/corlib/System/AppDomain.cs:762

Why is my C# AppDomain fine one moment, then throws exceptions the next?

I have an AppDomain that I'm using to load modules into a sandbox with:
class PluginLoader
{
public static AppDomain PluginSandbox;
static PluginLoader()
{
AppDomainSetup ads = new AppDomainSetup();
ads.ApplicationName = "Plugin Modules";
PermissionSet trustedLoadFromRemoteSourceGrantSet =
new PermissionSet(PermissionState.Unrestricted);
PluginSandbox =
AppDomain.CreateDomain("Plugin App Domain",
null, ads, trustedLoadFromRemoteSourceGrantSet);
}
And then later on, I'll pull in the DLL I need and create an object instance:
public IPlugin FindPlugin(string pluginName)
{
ObjectHandle handle =
PluginSandbox.CreateInstance(pluginName,
"Plugins." + pluginName);
IPlugin ip = (IPlugin)handle.Unwrap();
return ip;
}
I run through this a couple of times with no problems. Getting instances of various objects out in the Sandbox, with no problems.
A bit later in the code, in another method, I need to find the assembly to get an embedded resource (a compiled in data file, with ManifestResource). So I call:
Assembly [] ar = PluginSandbox.GetAssemblies();
And the error gets thrown:
A first chance exception of type 'System.IO.FileNotFoundException'
occurred in PluginRunner.dll.
Additional information: Could not load file or assembly '10wl4qso,
Version=1.0.3826.25439, culture info=neutral, PublicKeyToken=null'
or one of its dependencies. The system cannot find the file specified.
I'm not surprised. '10wl4qso' isn't the name of the assembly, the dll, or anything like it. In fact it seems pseudo-random for each run. Plus the added fun of GetAssemblies isn't even documented to throw this exception.
Now I can call GetAssemblies right after I get the initial object just fine, and everything is peachy. But a couple of seconds later, in a different method I get this. Being remoted, PluginSandbox has no useful information at all in the debugger.
I'm catching UnhandledException and DomainUnload on the AppDomain and neither is being triggered.
Why does my AppDomain suddenly not know about its assemblies?
Where's that garbage data coming from?
What can I do to prevent either/both of these from happening?

This weird named assembly you're seeing is probably generated by XmlSerializer. The XML serializer will output a dynamic assembly to be able to quickly serialize and deserialize a specific type quickly. Check your code for uses of XmlSerializer, comment them out and see if the problem occurs again.

I don't know if it helps you...
Try to override InitializeLifeTimeService on IPlugin. Your IPlugin implementation should inherits from MarshalByRefObject first.
public class PluginSample : MarshalByRefObject, IPlugin
{
public overrides object InitializeLifetimeService()
{
return null; //Return null to infinite object remote life.
}
//...implementation
}
Take a look at this article:
RemotingException when raising events across AppDomains