Use DLR to run code generated with CompileAssemblyFromSource?

Question

Following up on this excellent answer, I'm wondering if the DLR using the dynamic keyword can allow a less verbose way of writing code for the generated assembly.

For example, can the aforementioned answer's code:

using (Microsoft.CSharp.CSharpCodeProvider foo = 
           new Microsoft.CSharp.CSharpCodeProvider())
{
    var res = foo.CompileAssemblyFromSource(
        new System.CodeDom.Compiler.CompilerParameters() {  
            GenerateInMemory = true 
        }, 
        "public class FooClass { public string Execute() { return \"output!\";}}"
    );

    var type = res.CompiledAssembly.GetType("FooClass");
    var obj = Activator.CreateInstance(type);
    var output = type.GetMethod("Execute").Invoke(obj, new object[] { });
}

become something like:

using (Microsoft.CSharp.CSharpCodeProvider foo = 
           new Microsoft.CSharp.CSharpCodeProvider())
{
    var res = foo.CompileAssemblyFromSource(
        new System.CodeDom.Compiler.CompilerParameters() {  
            GenerateInMemory = true 
        }, 
        "public class FooClass { public string Execute() { return \"output!\";}}"
    );

    var type = res.CompiledAssembly.GetType("FooClass");
    dynamic obj = Activator.CreateDynamicInstance(type);
    var output = obj.Execute();
}

Yes, there's a bit less code. Make it work by using `Activator.CreateInstance()` instead. I don't see a question otherwise. — Hans Passant, Jun 06 '12 at 12:51
Yes I just tried it and realized that it "just works" with `dynamic` instead of `var`. Pretty cool stuff. — , Jun 06 '12 at 12:52

Steven Doggart · Accepted Answer · 2012-06-07T11:57:35.420

Yes, you can do that and it works well. However, while using the dynamic keyword is more convenient, it utilizes late-binding and is still just as unsafe, in that sense, as explicitly using reflection. If your design allows it, it is even better to use a shared interface or base class for early-binding. You can do this by creating a public type in your assembly or in a third, shared assembly, and then add a reference to that assembly from the new one you are dynamically compiling. Then, in the generated code, you can inherit from that shared type in the referenced assembly. For instance, create an interface:

public interface IFoo
{
    string Execute();
}

Then dynamically compile the assembly like this:

using (Microsoft.CSharp.CSharpCodeProvider foo = new Microsoft.CSharp.CSharpCodeProvider())
{
    var params = new System.CodeDom.Compiler.CompilerParameters();
    params.GenerateInMemory = true;

    // Add the reference to the current assembly which defines IFoo
    params.ReferencedAssemblies.Add(Assembly.GetExecutingAssembly().Location);

    // Implement the IFoo interface in the dynamic code
    var res = foo.CompileAssemblyFromSource(params, "public class FooClass : IFoo { public string Execute() { return \"output!\";}}");
    var type = res.CompiledAssembly.GetType("FooClass");

    // Cast the created object to IFoo
    IFoo obj = (IFoo)Activator.CreateInstance(type);

    // Use the object through the IFoo interface
    obj.Execute();
}

Depending on how much control you have over the dynamic code, this may or may not be possible, but when it is, it's nice to have the compile-time type-checking. For instance, if you tried to execute:

IFoo obj = (IFoo)Activator.CreateInstance(type);
obj.Execcute();

That second line would immediately fail to compile because it's spelled wrong, whereas with the dynamic keyword or reflection, that line would successfully compile but it would cause a run-time exception. For instance, the following will not get a compile-time error:

dynamic obj = Activator.CreateDynamicInstance(type);
obj.Execcute();

thanks for the elaborate answer (+1), but I have to disagree with your statement "while it is more convenient to do it that way, neither way is type-safe". Binding errors can occur because type safety is assured. Your statement would be correct with the opposite scenario where no binding error would occur when should. — , Jun 07 '12 at 08:01
I'm not sure exactly what you mean, but I modified my answer to make it more clear. — Steven Doggart, Jun 07 '12 at 11:58
I believe I was quite clear by saying that you were incorrect in saying that the approach is not type safe. — , Jun 07 '12 at 12:36

score 0 · Answer 2 · answered Jun 06 '12 at 12:52

0

That is one of the scenarios that the DLR was designed for. You can use it that way to invoke members of a dynamically loaded type while avoiding all of the extra typing from manually calling .GetMethod() and .Invoke().

answered Jun 06 '12 at 12:52

Jon Senchyna

7,867
2
26
46

Exactly as the question shows in its example. Note the differences between the last two lines in each one. – Jon Senchyna Apr 17 '13 at 19:19

Use DLR to run code generated with CompileAssemblyFromSource?

2 Answers2

Linked