How to load assemblies located in a folder in .net

问题:

I'm making a console app on .Net Core platform and was wondering, how does one load assemblies (.dll files) and instantiate classes using C# dynamic features? It seems so much different than .Net 4.X and it's not really documented...

For example let's say I have a class library (.Net Core) and it has only one class:

namespace MyClassLib.SampleClasses
{
    public class Sample
    {
        public string SayHello(string name)
        {
            return $"Hello {name}";
        }

        public DateTime SayDateTime()
        {
            return DateTime.Now;
        }
    }
}

So the name of the dll file would be MyClassLib.dll and its located in /dlls/MyClassLib.dll.

Now I want to load this in a simple console app (.Net Core) and instantiate the Sample class and call the methods using dynamic features of C# in the following console app:

namespace AssemblyLoadingDynamic
{
    public class Program
    {
        public static void Main(string[] args)
        {
            // load the assembly and use the classes
        }
    }
}

Note: By .Net Core I mean RC2 version.

回答1:

Currently running against netcoreapp1.0 you don't actually need to go to the extent of implementing your own AssemblyLoader. There is a Default that exists which works just fine. (Hence @VSG24 mentioning that the Load doesn't do anything).

using System;
using System.Runtime.Loader;

namespace AssemblyLoadingDynamic
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var myAssembly = AssemblyLoadContext.Default.LoadFromAssemblyPath(@"C:\MyDirectory\bin\Custom.Thing.dll");
            var myType = myAssembly.GetType("Custom.Thing.SampleClass");
            var myInstance = Activator.CreateInstance(myType);
        }
    }   
}

with project.json looking like:

{
  "version": "1.0.0-*",
  "buildOptions": {
    "emitEntryPoint": true
  },

  "dependencies": {
    "Microsoft.NETCore.App": {
      "type": "platform",
      "version": "1.0.1"
    },
    "System.Runtime.Loader": "4.0.0"
  },

  "frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"
    }
  }
}

回答2:

Not sure if it's the best way to do it but here's what I came up with:

(Only tested on .Net Core RC2 - Windows)

using System;
using System.Linq;
using System.Reflection;
using System.Runtime.Loader;
using Microsoft.Extensions.DependencyModel;

namespace AssemblyLoadingDynamic
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var asl = new AssemblyLoader();
            var asm = asl.LoadFromAssemblyPath(@"C:\Location\Of\" + "SampleClassLib.dll");

            var type = asm.GetType("MyClassLib.SampleClasses.Sample");
            dynamic obj = Activator.CreateInstance(type);
            Console.WriteLine(obj.SayHello("John Doe"));
        }

        public class AssemblyLoader : AssemblyLoadContext
        {
            // Not exactly sure about this
            protected override Assembly Load(AssemblyName assemblyName)
            {
                var deps = DependencyContext.Default;
                var res = deps.CompileLibraries.Where(d => d.Name.Contains(assemblyName.Name)).ToList();
                var assembly = Assembly.Load(new AssemblyName(res.First().Name));
                return assembly;
            }
        }
    }
}

MyClassLib.SampleClasses is the namespace and Sample is the type aka class name.

When executed, it will try to load the SampleClassLib.dll compiled class library in the memory and gives my console app access to MyClassLib.SampleClasses.Sample (take a look at the question) then my app calls the method SayHello() and passes "John Doe" as name to it, Therefore the program prints:

"Hello John Doe"

Quick note: The override for the method Load doesn't matter so you might as well just replace its content with throw new NotImplementedException() and it shouldn't affect anything we care about.

回答3:

Thanks for your sharing. It is working with Net Core 1.0 also. If your assembly needs another assemblies at the same path, you can use the code sample below.

using System.IO;
using System.Linq;
using System.Reflection;
using System.Runtime.Loader;
using Microsoft.Extensions.DependencyModel;
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))
            {
                var asl = new AssemblyLoader(apiApplicationFileInfo.DirectoryName);
                return asl.LoadFromAssemblyPath(apiApplicationFileInfo.FullName);
            }
        }
        return Assembly.Load(assemblyName);
    }
}

Remember to add the following dependencies to your project.json file:

 "System.Runtime.Loader"
 "Microsoft.Extensions.DependencyModel"

回答4:

Using .net core 1.1 / standard 1.6, I found that AssemblyLoader was not available, and

AssemblyLoadContext.Default.LoadFromAssemblyPath(assemblyPath)

gave me a "Could not load file or assembly xxx" error.

Finally this solution below worked for me - purely by adding a step to get the AssemblyName object. Hope it helps anyone who gets stuck:

var assemblyName = AssemblyLoadContext.GetAssemblyName(assemblyPath);
var assembly = Assembly.Load(assemblyName);

回答5:

@Rob, the only way I could get your example to build was to change your "myInstance" type to dynamic.

Leaving the type as var does allow the code to build but as soon as I try and use a method from the runtime loaded assembly, I get compiler errors such as myInstance does not contain method X. I'm new at this but marking the type as dynamic, does seem to make sense. If the type is loaded at runtime then how can the compiler verify myInstance will contain method X or prop Y ? By typing the myInstance as dynamic I believe you are removing the compiler checking and thus I could get the example to build and run just fine. Not sure this is 100% the correct way ( I don't know enough and you may advise that there's an issue using dynamic?) but it is the only way I got it to work without having to go to the trouble of creating my own AssemblyLoader (as you correctly point out).

So...

using System;
using System.Runtime.Loader;

namespace TestApp
{
    class Program
    {
        static void Main(string[] args)
        {
            var myAssembly = AssemblyLoadContext.Default.LoadFromAssemblyPath(@"C:\Documents\Visual Studio 2017\Projects\Foo\Foo\bin\Debug\netcoreapp2.0\Foo.dll");
            var myType = myAssembly.GetType("Foo.FooClass");
            dynamic myInstance = Activator.CreateInstance(myType);
            myInstance.UpperName("test");
        }
    }
}

Hope this helps someone as being new it took me ages to pinpoint why myInstance as a var didn't have method X etc Doh!

回答6:

I dig a lot into that, I tried the DependencyContext approach... It works well but it has some limitations and it is different from the standard assembly resolution that is in the the c++ dotnet app that starts your app. You have to do name matching manually and if your host app is a published one, you won't have the probing path for the nuget folder which is a problem (solveable) if your child assembly is in debug and uses nuget...

So here is another solution: If the app (assemblyA) manually loading an assembly (assemblyB) has no dependencies (or no conflicting dependencies with assemblyB) I suggest cheating and defaulting to the assembly resolution of assemblyB. There is an hidden gem for dotnet.exe that enable you to load the deps file of your choice so you can do something like this:

dotnet exec --depsfile pathToAssemblyB\assemblyB.deps.json --runtimeconfig pathToAssemblyB\assemblyB.runtimeconfig.json AssemblyA.dll

and then you can load the assembly as explained in other answers with

var myAssembly = AssemblyLoadContext.Default.LoadFromAssemblyPath("pathToAssemblyB\\AssemblyB.dll");

This way it will correctly resolve all dependencies for assemblyB but won't for assemblyA. It is a reverse problem but if you have a small app that want to do some remoting in a big app, it is useful. Another problem is that you need to know that you are going to use assemblyB when starting your app and that it works only once per execution. So there is a different set of problems and you can choose your approach depending on your situation. Please note that it is an unsupported/undocumented feature but it is used in EF core tooling, so it is "viable" for now...