Loading DLLs at runtime in C#

Question

I am trying to figure out how you could go about importing and using a .dll at runtime inside a C# application. Using Assembly.LoadFile() I have managed to get my program to load the dll (this part is definitely working as I am able to get the name of the class with ToString()), however I am unable to use the 'Output' method from inside my console application. I am compiling the .dll then moving it into my console's project. Is there an extra step between CreateInstance and then being able to use the methods?

This is the class in my DLL:

namespace DLL
{
    using System;

    public class Class1
    {
        public void Output(string s)
        {
            Console.WriteLine(s);
        }
    }
}

and here is the application I want to load the DLL

namespace ConsoleApplication1
{
    using System;
    using System.Reflection;

    class Program
    {
        static void Main(string[] args)
        {
            var DLL = Assembly.LoadFile(@"C:\visual studio 2012\Projects\ConsoleApplication1\ConsoleApplication1\DLL.dll");

            foreach(Type type in DLL.GetExportedTypes())
            {
                var c = Activator.CreateInstance(type);
                c.Output(@"Hello");
            }

            Console.ReadLine();
        }
    }
}

Solution 1

Members must be resolvable at compile time to be called directly from C#. Otherwise you must use reflection or dynamic objects.

Reflection

namespace ConsoleApplication1
{
    using System;
    using System.Reflection;

    class Program
    {
        static void Main(string[] args)
        {
            var DLL = Assembly.LoadFile(@"C:\visual studio 2012\Projects\ConsoleApplication1\ConsoleApplication1\DLL.dll");

            foreach(Type type in DLL.GetExportedTypes())
            {
                var c = Activator.CreateInstance(type);
                type.InvokeMember("Output", BindingFlags.InvokeMethod, null, c, new object[] {@"Hello"});
            }

            Console.ReadLine();
        }
    }
}

Dynamic (.NET 4.0)

namespace ConsoleApplication1
{
    using System;
    using System.Reflection;

    class Program
    {
        static void Main(string[] args)
        {
            var DLL = Assembly.LoadFile(@"C:\visual studio 2012\Projects\ConsoleApplication1\ConsoleApplication1\DLL.dll");

            foreach(Type type in DLL.GetExportedTypes())
            {
                dynamic c = Activator.CreateInstance(type);
                c.Output(@"Hello");
            }

            Console.ReadLine();
        }
    }
}

Solution 2

Right now, you're creating an instance of every type defined in the assembly. You only need to create a single instance of Class1 in order to call the method:

class Program
{
    static void Main(string[] args)
    {
        var DLL = Assembly.LoadFile(@"C:\visual studio 2012\Projects\ConsoleApplication1\ConsoleApplication1\DLL.dll");

        var theType = DLL.GetType("DLL.Class1");
        var c = Activator.CreateInstance(theType);
        var method = theType.GetMethod("Output");
        method.Invoke(c, new object[]{@"Hello"});

        Console.ReadLine();
    }
}

Solution 3

You need to create an instance of the type that expose the Output method:

static void Main(string[] args)
    {
        var DLL = Assembly.LoadFile(@"C:\visual studio 2012\Projects\ConsoleApplication1\ConsoleApplication1\DLL.dll");

        var class1Type = DLL.GetType("DLL.Class1");

        //Now you can use reflection or dynamic to call the method. I will show you the dynamic way

        dynamic c = Activator.CreateInstance(class1Type);
        c.Output(@"Hello");

        Console.ReadLine();
     }

Comments

[Reed Copsey]

Note that this tries to call Output on every type in the assembly, which will likely throw before the "right" class is found...

[Dark Falcon]

@ReedCopsey, Agreed, but for his simple example, his type is the only one visible. "The only types visible outside an assembly are public types and public types nested within other public types." For a non-trivial example, obviously this will be an issue...

[Niels Abildgaard]

Neat with the two examples! :)

[AaronLS]

This is why interfaces are often used and you can do feature detection such as IDog dog = someInstance as IDog; and test if it is not null. Put your interfaces in a common DLL shared by clients, and any plugin that will be loaded dynamically must implement that interface. This will then let you code your client against the IDog interface and have intellisense+strong type checking at compile time rather than use dynamic.

[Yaser Har]

Thank you so much - this is just what I am looking for. I can't believe this isn't higher rated than the other answers, since it shows the use of the dynamic keyword.

[Yaser Har]

Ah, now I see it was in DarkFalcon's answer as well. Yours was shorter and made it easier to see, though. :)

[ChrisH]

Wow, not sure why the down-votes. I have a production application doing exactly this for like the past 12 years. * shrug * Anyone needs some code to do this, shoot me a message. I'll package up portions of my production code and send it along.

[Alan Deep]

you may put c.Output in a try catch block and when you catch the exception continue so that as @ReedCopsey said this doesn't throw before the class is found.

[Shadow]

I suspect the downvotes would have to do with the lack of examples and condensing tone... Seems like you have the basis for a full answer though, so don't be afraid to edit in more details :)

[Tarek.Mh]

For the first note, you can use 'object' instead of 'dynamic', and test the type before using it, like: \r\n object obj = Activator.CreateInstance(type); \r\n if (obj is Class1) { obj.Output("Hello1"); }

[Dark Falcon]

@Tarek.Mh: That would require a compile-time dependency on Class1. At that point you can just use new Class1(). The asker explicitly specified a runtime dependency. dynamic allows the program to not require a compile-time dependency on Class1 at all.

[ABPerson]

It's just kind of rude to say "this is pretty simple stuff", and that's why got you the downvotes.

[ChrisH]

I wasn't being rude or condescending.... 6 years ago. Tone doesn't come through in text, clearly. It was really meant to be pretty light hearted... I also really feel like I had a link to a code sample in there all those years, and I have no idea where it went (assuming it really was there like I'm remembering). :\

[SpaghettiCook]

I don't know how MethodInfo works but it seems valuable. I'd say your answer has the potential to be better than the current accepted one but it would need to be completed. If you ever get around to it it would be appreciated. If so, please don't link to a code sample. These may get broken in the future. It is best to provide the sample yourself, with possibly a link to a source or extra info for continued reading.