This post demonstrates how to add assembly references to the Visual Studio Project the T4 template resides in.

Background

Sometimes the output code generated by a T4 template uses imports from an assembly that has not been referenced by the containing Visual Studio project yet. So on the first build attempt the user receives corresponding compile errors and has to add the references manually.

So why not enable the template to add necessary references to the project while generating the output code?

HowTo

In order to gain access to the Visual Studio project we use classes from the Visual Studio automation classes. This requires the T4 template to reference the EnvDTE.dll and the VsLangProj.dll. Add the following directives to the header of your template:

This example shows how to attach a T4 Template file to a given input file so that the template is transformed each time the input file is saved.

Background

In most scenarios T4 template are used to transform the contents of a given file into a different format (C# code, XML, …). That way the T4 template file becomes dependent on the input file. The usual workflow then is: edit the input file, save the input file and transform the template again to make sure that all changes are transformed again.

From time to time one might simply forget to transform the template after editing the input file. That’s when it would be great to have the edit-save-generate procedure in one simple step. This is where the “Dependent Templates” feature of the tangible T4 Editor comes into play.

It is common to use Reflection to explore namespaces, types and classes when running in a .NET application. But T4 Templates generate output code during Design Time. So there are no compiled assemblies yet that could be reflected or that ones available are from the last build and outdated.

In order to get information on what classes will be available in your assembly to be used inside a T4 Template, you need to access the Visual Studio CodeModel of the current project that is available at Design Time.

Access the Code Model

Using the Visual Studio Code Model you can access the following artifacts of your code at Design Time:
Types, Namespaces, Structures, Interfaces, Classes, Enumerations, Variables, Delegates, Properties and Functions. These Artifacts can be accessed via the CodeModel-Property of a EnvDTE.Project class or the Property “FileCodeModel” of a EnvDTE.ProjectItem.

This is the last part of the blog series about some of tangible engineering’s contributions to a Model Driven Development process in software development. In this part we are going to create a basic generic user interface that allows users to explore and manipulate data from any domain specific model created as a Persistent Object Model.

This part of the Model Driven Development blog series creates persistence layer (based on SQL Server) for the domain specific model built in Part 2 of the series using the C# code classes for Entity Framework 5.0 generated by a T4 template in Part 3.

The next blog post will create a basic user interface for interacting with the data objects and storing them in a SQL Server relational database.

Blog Series Overview

Part 1: Model Driven Development and Series Overview