Użyj funkcji DLR do uruchomienia kodu wygenerowanego za pomocą CompileAssemblyFromSource?

Question

Kontynuując ten excellent answer, zastanawiam się, czy DLR za pomocą słowa kluczowego dynamic może pozwolić na mniej szczegółowy sposób pisania kodu dla wygenerowanego zespołu.

Można na przykład kod wymienionej powyżej zwrotna:

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[] { }); 
} 

stać się coś takiego:

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(); 
} 

Answer 1

Tak, możesz to zrobić i działa dobrze. Jednak korzystanie z dynamicznego słowa kluczowego jest wygodniejsze, ponieważ wykorzystuje późniejsze wiązanie i nadal jest tak samo niebezpieczne, w tym sensie, jak jawnie za pomocą refleksji. Jeśli twój projekt na to pozwala, lepiej jest użyć wspólnego interfejsu lub klasy bazowej do wczesnego wiązania. Można to zrobić, tworząc typ publiczny w zespole lub w trzecim zespole współużytkowanym, a następnie dodać odwołanie do tego zestawu z nowego zestawu dynamicznie kompilowanego. Następnie w wygenerowanym kodzie można dziedziczyć z tego typu współużytkowanego w zespole referencyjnym. Na przykład utworzyć interfejs:

public interface IFoo 
{ 
    string Execute(); 
} 

Następnie dynamicznie skompilować zespół tak:

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(); 
} 

W zależności od tego, jak dużo kontroli masz nad kodem dynamicznym, to może być lub może nie być możliwe, ale kiedy to jest, miło jest mieć kontrolę typu kompilacji. Na przykład, jeśli próbował wykonać:

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

To druga linia natychmiast nie skompilować, ponieważ jest napisane źle, natomiast z dynamicznym słowa kluczowego lub refleksji, że linia będzie pomyślnie skompilować, ale spowodowałoby to run-time wyjątek. Na przykład poniższe błędy nie będą miały błędu kompilacji:

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

Answer 2

To jeden ze scenariuszy, że DLR został zaprojektowany dla. Możesz go użyć w ten sposób, aby wywołać członków dynamicznie ładowanego typu, unikając jednocześnie dodatkowego pisania z ręcznego wywoływania .GetMethod() i .Invoke().