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.
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)
MyClassLib.SampleClasses
is the namespace andSample
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 toMyClassLib.SampleClasses.Sample
(take a look at the question) then my app calls the methodSayHello()
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 withthrow new NotImplementedException()
and it shouldn't affect anything we care about.Using .net core 1.1 / standard 1.6, I found that AssemblyLoader was not available, and
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:
@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...
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!
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.
Remember to add the following dependencies to your
project.json
file: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:
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...
Currently running against
netcoreapp1.0
you don't actually need to go to the extent of implementing your ownAssemblyLoader
. There is aDefault
that exists which works just fine. (Hence @VSG24 mentioning that theLoad
doesn't do anything).with
project.json
looking like: