Czy możemy skonstruować zespół zarówno z CodeExpressions, jak i literalnego kodu źródłowego w tym samym czasie?

Question

Mam sytuację, w której jedna część mojego kodu jest generowana przez CodeExpressions, a druga przez samego użytkownika (jak w: użytkownik po prostu pisze swój kod jak zwykle, który bym wtedy wziął i dodał do mojego zespołu, gdy kompilował) .

Czy można wygenerować zestaw złożony z obu tych elementów? Zastrzeżenie: te dwa podejścia będą zawierać klasy partial, więc muszą znajdować się w tym samym zespole.

Innym podejściem, które miałem na myśli, było prawdopodobnie przetłumaczenie obu na reprezentację ciągów, a następnie wygenerowanie złożenia z tego ciągu, ale wątpię, czy mogę uzyskać kod źródłowy z typu wygenerowanego przez użytkownika (podczas kompilacji czas).

Pracując nad tym pomysłem, mógłbym napisać kod wygenerowany przez CodeExpressions do pliku tekstowego i połączyć go z plikami .cs. Oś czasu będzie wyglądać następująco:

• Użytkownik nie napisał jego zajęcia
• CodeDom drzewo jest ustawiony programowo
• Użytkownik buduje projekt
• CodeDom generuje źródło do pliku tekstowego
• program odczytuje zawartość użytkownika -defined .cs file
• Program odczytuje wygenerowany plik tekstowy
• Program łączy te dwa
• Program tworzy nowy .dll z połączonych kodu źródłowego

mogłem pominąć (redundantne) etapy pisania i czytania mojego wygenerowanym źródła CodeDom do pliku tekstowego i po prostu zapisać go w pamięci, a także, oczywiście. W rzeczywistości najłatwiej byłoby użyć wstępnie przetworzonych szablonów T4 i załadować wyniki tych szablonów do pamięci i skompilować złożenie z tego łańcucha.

Jak widać, jest bardzo brudny, ale teraz wygląda na najbardziej wykonalny. Czy przejrzałem jakieś opcje, które mogłyby to ułatwić?

Background:

Tworzę biblioteki, które będą tworzyć zespół z klas, które są zdefiniowane przez użytkownika. Sposób ten działa w następującej kolejności:

• Użytkownik odwołuje moją bibliotekę w swoim projekcie
• użytkownik tworzy nowy TinyTypeSetup instancji
• Użytkownik dodaje definicji typu małe, aby je
• użytkownik uruchamia programowi
• Program generuje zestaw z podanych typów za pomocą CodeDom

Co próbuję teraz dodać to możliwość Aby użytkownik mógł tworzyć własne pliki źródłowe i dodawać te pliki natychmiast do zespołu, który zostanie wygenerowany. Umożliwiłoby to użytkownikowi wybranie klas częściowych za pomocą własnych metod, a także tych, które sam generuję.

Answer 1

Nie mówisz o scenariuszu, w którym CodeExpression jest zawsze przydatny. Jest to generator kodu źródłowego, określony rodzaj kodu źródłowego, który jest generowany, jest określony przez wybranego usługodawcę.

Ale w żadnym momencie użytkownik twojego projektu nie dba o ten język w twoim planowanym użyciu. On nigdy na to nie patrzy, sam nigdy go nie kompiluje. Tylko ci zależy, musisz wybrać odpowiedni CodeCompiler. Użytkownik wybiera tylko zestaw, który produkuje. I przez konwencje .NET język, który był używany do tworzenia zespołu, nigdy nie ma znaczenia. Metadane wewnątrz zespołu są całkowicie neutralne językowo.

CodeObjects są przydatne w scenariuszu, w którym kod źródłowy jest automatycznie generowany i dodawany do projektu użytkownika. Kompilacja, później, gdy użytkownik tworzy swój projekt. Dobrymi przykładami są różne konstruktory wbudowane w Visual Studio, takie jak projektant zasobów i projektant WinForm. Z konieczności muszą one wygenerować kod zgodny z typem projektu użytkownika.

Należy zdecydowanie unikać, jeśli nie jest to potrzebne. Największe rozłączenie z generatorami kodu CodeDom polega na tym, że jest on w stanie wygenerować tylko podzbiór instrukcji, które są ważne w danym języku. I oczywiście brzydki w użyciu, to zaśmieca twój kod. Trzeba tylko wygenerować tekst, wybrany język nie ma znaczenia. Ponieważ wydajesz się preferować C#, jest to rodzaj tekstu, który powinieneś wygenerować.

Należy rozważyć większe rozwiązanie. Prawdopodobnie działałoby to o wiele lepiej, gdyby użytkownik faktycznie otworzył niestandardowego projektanta wewnątrz samego Visual Studio. Tak więc ten dodatkowy krok, który sprawia, że ​​translator przechodzi z TinyType do zespołu, nie jest już potrzebny. Łatwiejszy w użyciu, oświetla również IntelliSense. Teraz ma ma sens generowania kodu. To zajmie dużo pracy, tworzenie projektantów nie jest takie proste. Trzymaj oczy na piłce, żaden użytkownik nie będzie zadowolony z generowania tego pliku XML, którego potrzebujesz. Tworzenie małych typów w języku C# jest już łatwe, po prostu nie wymaga wiele pomocy. Tak czy inaczej, użytkownik komponujący własne typy ze swoich małych typów po prostu nie potrzebuje żadnej pomocy. VS już obsługuje go bezpośrednio.

Answer 2

Chociaż istnieje trochę krzywej uczenia się. Ale z pewnością lepiej niż samemu radzić sobie z sznurkiem. Patrząc w .NET Compiler Platform (Roslyn) dla perspektyw może pomóc, Overview to start with.

Dostarcza analizy semantycznej & możliwości transformacji API. Możliwości diagnostyczne i naprawcze kodu.