Przekompiluj C# podczas pracy, bez AppDomains

Istnieje teraz dość eleganckie rozwiązanie, możliwe dzięki (A) nowej funkcji w. NET 4.0 i (B) Roslyn.

Zestawy Kolekcjonerskie

W. NET 4.0, możesz określić AssemblyBuilderAccess.RunAndCollect podczas definiowania zestawu dynamicznego, co sprawia, że zestaw dynamiczny może być kolekcjonowany:

AssemblyBuilder ab = AppDomain.CurrentDomain.DefineDynamicAssembly(
    new AssemblyName("Foo"), AssemblyBuilderAccess.RunAndCollect);

Z vanilla. NET 4.0, i myślę, że musisz wypełnić dynamiczny montaż, pisząc metody w surowym IL.

Roslyn

Enter Roslyn: Roslyn pozwala kompilować surowy kod C# w dynamiczny zespół. Oto przykład, zainspirowany tymi dwoma blogami posty , zaktualizowane do pracy z najnowszymi binariami Roslyn:

using System;
using System.Reflection;
using System.Reflection.Emit;
using Roslyn.Compilers;
using Roslyn.Compilers.CSharp;

namespace ConsoleApplication1
{
    public static class Program
    {
        private static Type CreateType()
        {
            SyntaxTree tree = SyntaxTree.ParseText(
                @"using System;

                namespace Foo
                {
                    public class Bar
                    {
                        public static void Test()
                        {
                            Console.WriteLine(""Hello World!"");
                        }
                    }
                }");

            var compilation = Compilation.Create("Hello")
                .WithOptions(new CompilationOptions(OutputKind.DynamicallyLinkedLibrary))
                .AddReferences(MetadataReference.CreateAssemblyReference("mscorlib"))
                .AddSyntaxTrees(tree);

            ModuleBuilder helloModuleBuilder = AppDomain.CurrentDomain
                .DefineDynamicAssembly(new AssemblyName("FooAssembly"), AssemblyBuilderAccess.RunAndCollect)
                .DefineDynamicModule("FooModule");
            var result = compilation.Emit(helloModuleBuilder);

            return helloModuleBuilder.GetType("Foo.Bar");
        }

        static void Main(string[] args)
        {
            Type fooType = CreateType();
            MethodInfo testMethod = fooType.GetMethod("Test");
            testMethod.Invoke(null, null);

            WeakReference weak = new WeakReference(fooType);

            fooType = null;
            testMethod = null;

            Console.WriteLine("type = " + weak.Target);
            GC.Collect();
            Console.WriteLine("type = " + weak.Target);

            Console.ReadKey();
        }
    }
}

Podsumowując: z collectible assemblies i Roslyn, możesz skompilować kod C# do zestawu, który można załadować do AppDomain, a następnie zebrać śmieci(z zastrzeżeniem szeregu zasad ).

Cóż, chcesz być w stanie edytować rzeczy w locie, prawda? to jest twój cel, prawda?

Kiedy kompilujesz i ładujesz zestawy, jest teraz sposób na ich rozładowanie, chyba że rozładujesz swoją AppDomain.

Możesz załadować wstępnie skompilowane zestawy za pomocą zestawu.Załaduj metodę, a następnie wywołaj punkt wejścia przez odbicie.

Rozważyłbym podejście dynamicznego montażu. Gdzie za pośrednictwem bieżącej AppDomain powiedzieć, że chcesz utworzyć dynamiczny zespół. Tak działa DLR (dynamic language runtime). Dzięki złożeniom dynamicznym możesz tworzyć typy, które implementują jakiś widoczny interfejs i wywoływać je przez to. Z tyłu pracy z dynamic assemblies jest to, że musisz DOSTARCZYĆ poprawne IL samodzielnie, nie możesz po prostu wygenerować tego za pomocą wbudowanego kompilatora. NET, jednak założę się, że projekt Mono ma implementację kompilatora C#, którą możesz chcieć sprawdzić. Mają już interpreter C#, który odczytuje w pliku źródłowym C# i kompiluje to i wykonuje go, a to na pewno jest obsługiwane przez System.Odbicie.Emit API.

Nie jestem pewien co do zbierania śmieci tutaj, ponieważ jeśli chodzi o typy dynamiczne, myślę, że runtime ich nie zwalnia, ponieważ mogą być odwołane w dowolnym momencie. Tylko wtedy, gdy sam zespół dynamiczny zostanie zniszczony i nie będzie żadnych odniesień do tego zespołu, rozsądne byłoby uwolnienie tej pamięci. Jeśli jesteś i ponownie generując dużo kodu upewnij się, że pamięć jest, w niektórych punkt, zebrany przez GC.

Gdyby językiem była Java, odpowiedzią byłoby użycie JRebel. Ponieważ tak nie jest, odpowiedzią jest podniesienie poziomu hałasu, aby pokazać, że jest na to zapotrzebowanie. Może wymagać jakiegoś alternatywnego CLR lub 'C# engine project template' I VS IDE pracującego w koordynacji itp.

Wątpię, że jest wiele scenariuszy, w których jest to "must have", ale jest wiele, w których zaoszczędziłoby to dużo czasu, ponieważ można ujść na sucho z mniejszą infrastrukturą i szybszą realizacją rzeczy, które nie będą używany przez długi czas. (Tak są tacy, którzy twierdzą, że przesadzają z inżynierią rzeczy, ponieważ będą używane 20 + lat, ale problem z tym polega na tym, że trzeba zrobić jakąś masową zmianę, prawdopodobnie będzie to tak kosztowne, jak przebudowa całości od podstaw. Więc sprowadza się do tego, czy wydawać pieniądze teraz, czy później. Ponieważ nie jest pewne, że projekt stanie się później krytyczny biznesowo i może wymagać dużych zmian później tak czy inaczej, argumentem dla mnie jest użycie Zasady "KISS"i mieć złożoność edycji na żywo w IDE, CLR / runtime i tak dalej zamiast budowania go w każdej aplikacji, gdzie może być przydatny później. Z pewnością potrzebne będą pewne defensywne programowanie i ćwiczenia, aby zmodyfikować niektóre usługi na żywo za pomocą tego rodzaju funkcji. Jak mówi się o Erlang devs)