1. Einführung
1.1. Architektur
1.1.1. Komponenten
1.1.1.1. Engine
1.1.1.1.1. kontrolliert den text template transformation - Prozess
1.1.1.1.2. kann nicht an eigene Bedürfnisse angepasst werden
1.1.1.2. Host
1.1.1.2.1. Schnittstelle zwischen Engine und Benutzerumgebung (Visual Studio)
1.1.1.2.2. Verantwortlich für
1.1.1.2.3. kann angepasst werden
1.1.1.3. Directive Processors
1.1.1.3.1. Bereitstellen von zusätzlicher Funktionalität und Instruktionen für die Engine
1.1.1.3.2. Typen
1.1.2. Custom Tool
1.1.2.1. TextTemplate
1.1.2.1.1. TextTemplatingFileGenerator
1.1.2.2. PreProcessedTemplate
1.1.2.2.1. TextTemplatingFilePreprocessor
1.1.3. Verbesserungen mit VS 2010 SP1
1.1.3.1. assembly Direktive sperrt nicht mehr die DLL bis Solution geschlossen wird
1.1.3.1.1. bisher VolatileAssembly aus der T4-Toolbox
1.1.3.1.2. Fallback mit Registry-Key
1.1.3.2. Verbesserte Inheritance-Strategien
1.2. Sicherheit
1.2.1. Gefahren
1.2.1.1. Beliebiger Code innerhalb der Statementblocks möglich
1.2.1.2. Auf Schadcode anfälliger Directive Processor
1.2.1.3. Warnung auf eigene Gefahr
1.3. Prozessablauf
1.3.1. Quelle Oleg Sych
1.3.1.1. mit Speichern des Templates
1.3.1.1.1. Kompilierung
1.3.1.1.2. Ausführung
1.3.1.2. in 2 Schritten
1.3.1.2.1. 1. Schritt
1.3.1.2.2. 2. Schritt
1.4. Vorteile
1.4.1. Code Generator innerhalb der Solution
1.4.1.1. keine zusätzliche Software/Lizenz
1.4.1.2. besserer Überblick, was wurde automatisiert
1.4.1.2.1. mit Visual Studio Host
1.4.1.3. Transparenz
1.4.1.4. Vereinfachte Optimierung von Code
1.4.1.4.1. Bsp. SQL
1.4.1.4.2. Refactoring
1.4.1.4.3. Erweiterungen für bestimmte Funktionalität
1.4.1.5. nahtloses Zusammenspiel mit Entwicklungsumgebung
1.4.1.5.1. FileCodeModel
1.4.1.5.2. Automation Model
1.4.2. DSL/UML Konsistenz
1.4.2.1. ermöglicht die Übereinstimmung von Modell und Code
1.4.2.1.1. Entwurf
1.4.2.1.2. Implementierung
1.4.2.1.3. Dokumentation
1.4.2.2. Einfacher lesbar
1.4.2.3. Erstellen eigener DSL
1.4.3. Geringer Lernaufwand
1.4.3.1. Syntax angelehnt an klassischen ASP, PHP
1.4.3.2. kann C# oder VB innerhalb der Blöcke benutzen
1.4.4. Anpassbarkeit, Erweiterbarkeit
1.4.4.1. Einsatz für eigene Generatoren möglich
1.4.4.1.1. Verwendung in eigenen Anwendungen
1.4.4.1.2. Preprocessed Templates
1.4.5. Nicht an Wizards gebunden
1.4.5.1. Code entspricht nicht immer den Bedürfnissen
1.4.5.2. es wird mehr generiert als benötigt wird
1.4.5.3. Offen für neue Sprachen bzw. Diagramme
1.4.5.4. Wizard ist meist T4
1.4.6. Technologieunabhängig
1.4.6.1. beliebiger Text-Output
1.4.6.1.1. cs
1.4.6.1.2. vb
1.4.6.1.3. xml
1.4.6.1.4. sql
1.4.6.1.5. dtsx
1.4.6.1.6. resx
1.4.6.1.7. xaml
1.4.6.1.8. .java
1.4.6.1.9. uvm.
1.4.7. Codequalität kann verbessert werden
1.4.7.1. korrigierte Fehler im Template gehen nicht vergessen
1.4.7.2. keine Flüchtigkeits- oder Rechtschreibfehler
1.4.7.3. Gleichbleibende Qualität
1.4.7.4. Codeerstellung ist reproduzierbar
1.4.8. Produktivität kann gesteigert werden
1.4.8.1. Automatisierung stupider Aufgaben
1.4.8.1.1. Prozeduren für EF
1.4.8.1.2. Mockobjekte
1.4.8.1.3. Factories
1.4.8.1.4. Repositories
1.4.8.1.5. Schnittstellen
1.4.8.1.6. Unittests
1.4.8.2. Fehleranfälligkeit sinkt
1.4.8.3. Nachträglicher Änderungen sind einfacher möglich
1.4.8.4. T4 ist in den Entwicklungsprozess eingebunden
1.4.8.4.1. Prozessautomatisierung mit VS Automation Model
1.4.8.4.2. VS File Code Model
1.4.9. Kosten können bedingt gesenkt werden
1.4.9.1. Paretoprinzip beachten
1.4.9.2. Codegenerierung kann nicht vollständig ermöglicht werden
1.4.9.3. Mehr Zeit für Dinge die als erstes aus Kostengründen in einem Projekt wegrationalisiert werden
1.4.10. Blick auf die Kundenanforderungen
1.4.11. Zusammengefasst
1.4.11.1. Zusammenspiel mit Entwicklungswergzeug VS
1.4.11.2. Verwendung von DSL
1.4.11.3. Anpassen der Templates
1.4.11.4. Dinge die von einen guten Code Generator erwartet werden erfüllt T4
1.5. Nachteile/Herausforderungen
1.5.1. kein Intellisense
1.5.1.1. nur mit Zusatztools
1.5.1.1.1. tangible T4 Editor
1.5.2. keine volle Shortcut-Unterstützung
1.5.2.1. Bsp. CTRL K,C
1.5.3. keine Code Snippets
1.5.3.1. ebenfalls nur mit Zusatzstools
1.5.3.1.1. Snippet Support innerhalb der Statement Blocks
1.5.4. Refactoring-Tools wie CodeRush funktionieren nicht innerhalb der Statement and Class Feature Blocks
1.5.4.1. wird sich auch in naher Zukunft nicht ändern
1.5.4.2. Alternative Vote for S134920
1.5.5. gewohnte Komfort von VS kann zur Zeit auch nicht mit Zusatztools erreicht werden
1.5.6. kein Framework
1.5.6.1. T4 Toolbox
1.5.6.2. Keine Synchronisierung von Code und Model (leistungsschwache Versionen von VS)
1.5.6.2.1. Eigenimplementierung erforderlich
1.5.6.2.2. Bei gleichzeitiger Änderung von Code und Model ist ein Zusammenspiel erforderlich mit
1.5.6.2.3. Es gibt Tools auf den Markt die in dieser Hinsicht leistungsfähiger sind
1.5.6.3. HowTo's und Blogs
1.5.6.3.1. Nicht immer die optimalsten Lösungsansätze
1.5.7. MSDN Doku ist etwas dürftig
1.5.7.1. keine Informationen zu Preprocessed Templates (Vorverarbeitete Textvorlage)
1.5.7.1.1. mittlerweile besser
1.5.7.2. Gemeinsamkeit mit anderen Code Generatoren
1.5.8. Sicherheitslücken möglich
1.5.9. Unterlagen müssen in einer normalisierten Form vorliegen
1.5.9.1. Problem bei
1.5.9.1.1. unstrukturierten Unterlagen
1.5.9.1.2. proprioritären Formaten
1.5.9.2. Anforderungsdokumente liegen nicht immer so vor, dass diese für die Automatisierung genutzt werden können
1.5.10. Gefahren
1.5.10.1. Eierlegende Wollmilchsau
1.5.10.2. Spaghetti Code
1.5.10.2.1. Anpassen bestehender Templates
1.5.10.2.2. Fehlende Design-Überlegungen
1.5.10.2.3. Hintergrund
1.5.10.2.4. Aber
1.5.10.3. Code Qualität steigt nicht weiter
1.5.10.4. Generierte Technologie wird nicht angepasst
2. Aufbau eines Text Templates
2.1. Direktive
2.1.1. built-in
2.1.1.1. include
2.1.1.1.1. Registry
2.1.1.1.2. VS 2010
2.1.1.2. assembly
2.1.1.2.1. GAC
2.1.1.2.2. PublicAssembly Ordner
2.1.1.2.3. VS 2010
2.1.1.2.4. Mit VS 2010 SP 1 wird die Assembly nicht mehr gesperrt
2.2. Syntax
2.2.1. Statement
2.2.1.1. <# #>
2.2.2. Expression
2.2.2.1. <#= #>
2.2.2.1.1. Alternativ
2.2.3. Class Feature
2.2.3.1. <#+ #>
2.2.3.1.1. Hilfsfunktionen
2.2.3.1.2. Klassen
2.2.3.1.3. Keine Extension Methods
2.2.4. Processing Directive
2.2.4.1. <#@ #>
2.2.5. Textblock
2.3. Fehlerbehandlung
2.3.1. Error("Fehler");
2.3.2. Warning("Warnung");
2.3.3. Unbehandelte Fehler erzeugen einen Abbruch
2.3.4. Aber keine Information möglich
2.4. Extension Methods nur über Assembly
2.5. RunCustomTool
2.5.1. TextTemplatingFileGenerator
3. Werkzeuge
3.1. tangible t4
3.1.1. T4 Editor 1.9.64 Pro
3.1.1.1. Ermöglicht Ausführung während Buildvorgang
3.2. T4 Toolbox
3.3. MvcContrib
3.4. Clarius
3.5. Hilfsmittel Entwicklung zur Qualitätssteigerung
3.5.1. CAT.NET
3.5.2. FxCop
3.5.3. StyleCop
4. Szenarien
4.1. Beispiele
4.1.1. ADC 2010
4.1.1.1. Voraussetzungen
4.1.1.1.1. T4Toolbox
4.1.1.1.2. Entity Framework CTP4
4.1.1.1.3. Tangible T4-Editor
4.1.1.1.4. System.Diagnostics.Contracts
4.1.1.1.5. Excel 2007 oder höher
4.1.1.2. Hinweis
4.1.1.2.1. Mehrere Beispiele im Basic-Bereich arbeiten mit dem gleichen DemoArray
4.1.1.2.2. VsAutomationHelper.CS.tt liegt in einem Registry-Folder, deswegen keine Pfadangaben
4.1.1.2.3. Ursprungsklassen des FileCodeModelRefactoring liegen im backup-Verzeichnis des Beispiels
4.1.2. Webcast
4.2. Erstellen von Code-Dateien pro Klasse
4.2.1. Variante mit EF Filemanager
4.2.2. Einfache Variante
4.3. Erstellen von Dateien in andere Ordner und Projektmappen
4.4. Einmaliges Erstellen von Dateien/Klassen
4.5. Verwendung des VS Automation Model
4.6. Template mit Parameter
4.7. Verwenden von Warning und Error
4.8. Debugging von T4-Vorlagen
4.8.1. debug="true" in Template-Direktive
4.8.2. Debugger.Break()
4.8.2.1. Problem
4.8.2.1.1. Default-Installation stürzt ab (64bit)
4.8.2.1.2. Lösung
4.9. Include-Vorlagen
4.9.1. Class Block
4.9.1.1. Ausgabelogik (Write), wenn möglich nur im Sonderfall
4.9.2. VS 2010
4.9.2.1. Windows-Umgebungsvariable
4.9.2.1.1. %dev%\Name.tt
4.9.2.1.2. setx
4.9.2.2. VS Macro SolutionDir
4.9.2.2.1. <#@ assembly name="$(SolutionDir)t4inc\T4.tt" #>
4.10. Verwenden bestehender Logik
4.10.1. Verwenden eigener Assemblies
4.10.1.1. Vorteil
4.10.1.1.1. Einsatz von Extension Methods
4.10.1.1.2. Verwendung bereits existierender Logik
4.10.1.2. GAC
4.10.1.2.1. oder PublicAssembly-Verzeichnis von Visual Studio
4.10.1.3. File
4.10.1.4. Problem
4.10.1.4.1. Assembly gesperrt
4.10.1.4.2. Lösungen
4.11. Refactoring
4.12. Erstellen erweiterbarer Klassen
4.12.1. Vererbung
4.12.2. partial
4.12.2.1. Double derived pattern
4.12.2.1.1. DSL
4.12.2.1.2. bei Pattern-Fanatikern bevorzugen, um ziellose Diskussionen wegen partial zu vermeiden ;-)
4.13. Erstellen eigener VS Item Vorlagen
4.14. Preprocessed Templates
4.15. UML/XML
4.15.1. wenn API für C#
4.15.2. VS FileCodeModel
4.15.2.1. Roundtrip-E.
4.15.2.2. Sync
5. Zusammenfassung
5.1. Im Bereich DSL/UML trägt es zur Konsistenz bei
5.1.1. Diagramm - Code Konsistenz
5.1.2. Erstellen der Dokumentation
5.1.3. Technologisch flexibel
5.1.4. Offen für neue Diagrammformen, eigene DSL's
5.1.5. Nachteil
5.1.5.1. auch einfache Dinge erfordern eine Spezifikation (Attribute)
5.1.5.2. Unreife Diagramme
5.2. Man muss sich nicht mehr mit dem generierten Wizard-Code zufrieden geben
5.3. Anwendbar in eigenen Applikationen
5.4. Qualitätsverbesserungen
5.4.1. Stupiden Code automatisieren
5.4.2. Mehraufwand reduzieren
5.4.2.1. Store Proecedures
5.4.3. Refactoring vereinfachen
5.4.4. T4 Template versioniert mit Solution
5.4.5. Berücksichtigung eigener Prozesse
5.5. Bedienung und Handhabung weicht ab
5.5.1. Fehlende Shortcut-Unterstützung
5.5.2. Debugging
5.5.2.1. Haltepunkte
5.5.2.2. Launch() statt Break()
5.5.2.3. Eigenes Debugfenster
5.5.2.4. gelegentliche Abstürze
5.5.3. Der eigentliche Komfort von VS wird auch nicht mit Zusatztools erreicht
5.6. T4 Dokumentation beruht überwiegend auf Web 2.0 und Oleg Sych
5.7. Viele Beispile und Vorlagen erhält man mit tangible und der t4 toolbox
6. Ressourcen
6.1. MSDN
6.2. Webcast
6.3. Oleg Sych
6.3.1. u.a. Artikel zu MS Build Integration
6.4. tangible
6.5. T4 Editor Code Gallery
6.6. T4 toolbox
6.6.1. Beispiele
6.6.1.1. Prozeduren
6.6.1.2. Dateien erstellen mit Ordner und solution-Struktur
6.6.1.3. Vorgefertigte Templates
6.7. Chirpy
6.7.1. VS AddIn
6.7.2. Ermöglicht vereinfachteres Ausführen von Text Templates während des Buildvorgangs
6.7.3. Alternative zu TextTransform.exe mit Batch-Files
6.8. Gareth Jones
6.9. Blogbeiträge zum Thema T4
7. Designüberlegungen
7.1. Anpassung bestehender Templates
7.1.1. sollte ein Sonderfall bleiben, wenn es nicht die eigenen sind
7.1.1.1. Bsp. T4 Self Tracking Entities
7.2. Erweitern bestehender Template
7.2.1. Arbeiten mit partial
7.2.1.1. Bsp. Schnittsteleenerweiterung
7.3. Anlegen von Codeschablonen
7.3.1. Aufbereitung der Informationen
7.3.2. Ausgabe des Codes
7.3.2.1. Parametriesiertes Text Template
7.3.2.2. PreProcessed Template
7.4. Richtlinien im Team besprechen
7.4.1. Struktur
7.4.2. Logik
7.4.3. Sicherheitsaspekte
7.4.4. Kein Dogma
7.4.4.1. Glauben != Wissen
8. Aufbau eines Preprocessed Templates
8.1. Vorteile
8.1.1. Leichter zu debuggen
8.1.2. Intellisense ohne Zusatztools
8.1.2.1. in der partial class
8.1.3. Syntax und Kompilercheck
8.1.4. Keine feste Abhängigkeit zu Visual Studio
8.1.5. In beliebigen .NET-Anwendungen verwendbar
8.1.6. Erweiterbar
8.1.6.1. partial class
8.1.6.2. virtual TransformText
8.1.6.2.1. tricky
8.1.7. Generierten Code vor Änderungen schützen
8.1.7.1. bsp.
8.1.7.1.1. Validierung
8.2. Herausforderung
8.2.1. Preprocessed Texttemplates mit Referenzen zu anderen Dll´s
8.2.1.1. werden diese in normalen Textvorlagen verwendet, wird das auflösen dieser Dll´s tricky
8.2.1.2. Stichwort: Temp. AppDomain
8.3. Nicht unterstützt wird
8.3.1. Output Directive
8.3.2. Assembly Direktive
8.3.3. Debug-Parameter
8.4. Verhaltensänderung
8.4.1. template property Inherits
8.4.1.1. fehlt
8.4.1.1.1. Implementiert Standardbasisklasse
8.4.1.1.2. Implementiert Standardmethoden von TextTransformation
8.4.1.2. vorhanden
8.4.1.2.1. Implementierung der Basisklasse ist Aufgabe des Templateautors
8.4.1.2.2. ohne Standardmethoden
8.4.1.2.3. Templateautor ist für Implementierung verantwortlich
8.4.1.2.4. in diesen Szenario kann auch der Einsatz von hostspecific nützlich sein
8.5. RunCustomTool
8.5.1. TextTemplatingFilePreprocessor
9. Motivation
9.1. Bezug auf CodeDOM
9.1.1. sehr aufwendig
9.1.2. Codeerstellung auf Basis von XML
9.1.3. Kosten-/Nutenverhältnis für eigenen Szenarien
9.1.4. Theoretisch Erzeugung von vb, jscript, c#
9.1.4.1. CodeSnippetCompileUnit
9.1.5. Erzeugung beliebiger Technologien nicht möglich
9.1.5.1. PHP
9.1.5.2. SQL
9.1.6. Teil der .NET Framework-Klassenbibliothek