2013-02-10 17 views
10

Szukam System.CodeDom namespace dla niezależnego od języka (przynajmniej w pewnych granicach) generowania kodu źródłowego i znalazłem pewne informacje zniechęcające do korzystania z CodeDom.Czy istnieje oficjalny zamiennik CodeDom?

Myślę, że niektóre z pominięć opisanych w this early blogpost zostały już naprawione, a fakt, że CodeDom does not seem to provide a way to create a switch statement nadal pozwala na - mniej wydajności? - obejścia bez zniekształcania publicznego interfejsu generowanych typów. To samo dotyczy automatic C# properties i collection initializers.

Jednak innych pominięć naprawdę nie da się obejść, takich jak inability to create finalizers, impossibility to declare extension methods lub lacking direct support of generic reference type constraints.

Należy zauważyć, że je roztwory CodeSnippetTypeMember lub wstrzykiwania dosłownych fragmenty kodu źródłowego w jakikolwiek inny sposób nie jest zadowalające, ponieważ nie są niezależne od języka - usuwając cały punkt stosowania CodeDom zamiast String.Format z dosłownych fragmentów kodu.

Na koniec sugeruje się nawet, że "CodeDom to błąd, a drzewa Expression (a raczej drzewa" Statement ") są drogą naprzód" - choć bez żadnego wyjaśnienia, jak właściwie uzyskać kod źródłowy z expression tree (przy ograniczeniu, że classes cannot be declared with expression trees.

Is CodeDom nadal metodą z wyboru, że kod źródłowy wygenerowany, czy też obecny BCL oferuje żadnych niejasnych wymiany z nazwą, że nie myślę o?

+1

http://stackoverflow.com/questions/7852926/microsoft-roslyn-vs-codedom –

+0

@DavidBrabant (a także na [driis] (http://stackoverflow.com/users/13627/driis), który wskazywał to już wcześniej): Dziękuję, * Roslyn * to tylko jedna z nazw oprogramowania, których nie możesz znaleźć, chyba że już je znasz. Poświęcę trochę czasu na zapoznanie się z tym przed wyborem odpowiedzi odnoszącej się do tego jako przyjętego. –

+0

@ O.R.Mapper Myślę, że to samo dotyczy nazw większości technologii w .Net: LINQ, Entity Framework lub CodeDOM. – svick

Odpowiedz

4

myślę CodeDom jest nadal najlepszym rozwiązaniem w BCL dzisiaj, ale: Projekt Roslyn jest daleko i już uruchomił kilka CTP. Celem jest udostępnienie kompilatora jako usługi i umożliwi on tworzenie scenariuszy generowania kodu i inspekcji kodu za pomocą prostego interfejsu API.

Spójrz na to, jeśli możesz użyć bitów przedpremierowych do swojego projektu: Roslyn CTP. Oto powiązane (aczkolwiek nieaktualne, wciąż dobre informacje) pytanie StackOverflow: Microsoft Roslyn vs. CodeDom. I wreszcie artykuł, który mówi o użyciu Roslyn do generowania kodu: Code Generation in .NET with the Roslyn CTP

+2

Nie nazwałbym API prostym, szczególnie w porównaniu z CodeDOM. Na przykład, aby stworzyć prostą autoproperty, potrzebujesz [tego monstrualnego] (https://gist.github.com/svick/4749582). – svick

3

Nie. CodeDom przydaje się do generowania kodu do , wykonując. Jego zdolność do generowania tekstu była jedynie przypadkowym produktem ubocznym, ponieważ kompilatory potrzebują tekstu. Jeśli naprawdę zależy Ci na tekście, istnieje wiele powodów, aby nie lubić CodeDom i niczego w ramach, aby ci pomóc.

Inne rozwiązania są podobnie ukierunkowane na generowanie kodu wykonywalnego. Reflection.Emit generuje IL, uniwersalny język w .NET, ale nie oferuje prostego sposobu dekompilacji, chociaż przyzwoity dekompilator (ILSpy, Reflector, itp.) Z pewnością może pomóc. Linq.Expressions jest czystym kodem wykonywalnym i generalnie nie jest użyteczny do generowania kompletnych programów. Roslyn jest mocno uprzedzony wobec posiadania już tekstu.

Prawdopodobnie najlepszym rozwiązaniem jest wycofanie wymogu posiadania tekstu w określonym języku. Wszystkie kompilatory .NET mają ten sam rodzaj wyjścia, wszystkie kompilują się do IL. Co sprawia, że ​​ograniczenie wyboru języka do realnego podejścia jest możliwe. Z twojego pytania nie wynika jednoznacznie, czy jest to rozsądne ograniczenie. Wydaje się, że jest to powszechny wybór, nie mogę myśleć o projekcie, który kiedykolwiek próbował rozwiązać ograniczenia CodeDom. Rodzaj projektów dostępnych w codeplex.com, który celuje w CodeDom, zamiast tego starają się zminimalizować ból gadatliwości wymaganej w kodzie korzystającym z CodeDom.

+1

Tworzę bibliotekę, która może być skonfigurowana za pomocą plików Xml, i podczas gdy dostęp do wszystkiego zdefiniowanego w plikach Xml za pośrednictwem typów bibliotek jest możliwy przy sprawdzaniu w czasie wykonywania, jako dodatkowa usługa zapewniam narzędzie, które automatycznie tworzy kod dla klasy wrapper oparte na plikach konfiguracyjnych Xml. Dodałoby to korzyści z kompilacji, sprawdzając dostęp do rzeczy zdefiniowanych w plikach Xml. –

+0

Ten generator działa dobrze dla języka C#, ale byłoby miło również obsługiwać inne języki, więc projekty utworzone w innych językach .NET mogą zawierać pliki źródłowe klasy opakowania równie łatwo jak projekty C#. Zamiast pisać generator (który składa się głównie z fragmentów kodu źródłowego) zasadniczo od podstaw dla każdego języka, definiując klasy opakowania tylko raz jako abstrakcyjny model kodu, a następnie dostarczając go do generatora kodu źródłowego dla pożądanego języka, wydaje się, że o wiele czystsze rozwiązanie dla mnie. –

+1

Cóż, proszę. Znacznie prostsze jest, aby te inne projekty językowe dodawały odniesienie do zestawu generowanego przez CodeDom. Metadane w zespole są agnostyczne, każdy język .NET może go używać. –