Working with the T4

Update: Thanks to Tim Fischer from Tangible, I got to solve all the problems described in the post below using VolatileAssembly and macros like $(SolutionDir) or $(ProjectDir).

When T4 (Text Template Transformation Toolkit) appeared as a third party toolkit that you could install on Visual Studio 2008, I thought to myself that it is a cool concept, but I didn't get to actually use it. Now it is included in Visual Studio 2010 and I had the opportunity to use it in a project.

The idea is to automatically create code classes and other files directly in Visual Studio, integrated so that the files are generated when saving the template. All in all a wonderful idea... but it doesn't work. Well, I may be exaggerating a bit, but my beginning experience has been off putting. I did manage to solve all the problems, though, and this is what this blog post is about.

First of all, there is the issue of intellisense. I am using ReSharper with my Visual Studio, so the expectations for the computer knowing what I am doing are pretty high. In the .tt (the default extension for T4) files you don't have any. The solution for this is to use the Tangible T4 editor (I think they were going for a fifth T here) that comes as a Visual Studio addon for VS2008 and VS2010. Fortunately, there is a free version. Unfortunately, it doesn't do intellisense on your own libraries unless you buy the priced one. Also, the intellisense is years behind the one provided by ReSharper or even the default Visual Studio one and the actions one can do automatically on code in a T4 template are pretty limited.

The second problem was when trying to link to an assembly using a relative path to the .tt file. The Assembly directive supports either the name of an assembly loaded in the GAC or a rooted path. Fortunately, the VS2010 version of the T4 engine supports macros like $(SolutionDir). I don't know if it supports all Visual Studio build macros in the link, but the path ones are certainly there.

Here is how you use it. Instead of

<#@ Assembly Name="Siderite.Contract.dll" #>

use

<#@ Assembly Name="$(SolutionDir)/Assemblies/Siderite.Contract.dll" #>

The third problem was that using an assembly directive locked the assembly used until you either reopened the solution or renamed the assembly file. That proved very limiting when using assemblies that needed compiling in the same solution.

This can be solved by installing the T4 Toolbox and using the VolatileAssembly directive. Actually, on the link above from Oleg Sych you can also find a bit advising using the T4 toolbox VolatileAssembly directive in the Assembly Locking section.

Here is how you use it. Instead of

<#@ Assembly Name="$(SolutionDir)/Assemblies/Siderite.Contract.dll" #>

use

<#@ VolatileAssembly 
processor="T4Toolbox.VolatileAssemblyProcessor"
name="$(SolutionDir)/Assemblies/Siderite.Contract.dll" #>

As you can see you need to specify the processor (the VolatileAssemblyProcessor would have been installed by the T4 Toolbox) and you can use macros to get to a relative rooted path.

So thanks to the eforts of Oleg and Tim here, we can actually use T4. It would have been terribly akward to work with the solution in the obsolete section below. The Tangible guys have a learning T4 section on their site as well. I guess that using the resources there would have spared me from a day and a half wasted on this.

The following is obsolete due to the solutions described above, but it is still an informative read and may provide solutions for similar problems.

var path=Host.ResolvePath("../Assemblies/Work/Siderite.Contract.dll");

<#@ template  debug="true" hostSpecific="true" #>
<#@ output extension=".cs" #>
<#@ Assembly Name="System.Core.dll" #>
<#@ Assembly Name="System.Windows.Forms.dll" #>
<#@ import namespace="System" #>
<#@ import namespace="System.IO" #>
<#@ import namespace="System.Diagnostics" #>
<#@ import namespace="System.Linq" #>
<#@ import namespace="System.Collections" #>
<#@ import namespace="System.Collections.Generic" #> 
<#@ import namespace="System.Reflection" #>
<#@ include file="AssemblyLoader.ttinclude" #>
<#
    // resolve the relative path for the Contract assembly
        string path=Host.ResolvePath("../Assemblies/Work/Siderite.Contract.dll");
        // create a loader in another appdomain
        AssemblyLoader loader=AssemblyLoader.
      CreateInNewDomain("Template generation domain",Path.GetDirectoryName(path));
        // load the Contract assembly in the appdomain
        loader.LoadAssembly(path);
        // get the type we need to use reflection on in order to generate code
        Type type=loader.GetType("Siderite.Contract.IDataServiceFacade");
        // unload the appdomain and exit.
        AssemblyLoader.Unload(loader);
#> 
using System;
using System.ServiceModel;
using System.Reflection;
using System.ServiceModel.Channels;
using Siderite.Configuration;

namespace Siderite.Proxy
{
  // code of the generated class comes here
  // with <# code #> and <#= value #> tags in it
  // using the type variable from the Contract library to get the information I want
}

<#+
class AssemblyLoader : MarshalByRefObject
  {
    private Assembly _assembly;

    public AppDomain Domain
    {
      get;
      private set;
    }

    public override object InitializeLifetimeService()
    {
      return null;
    }

    public void LoadAssembly(string path)
    {
      _assembly = Assembly.Load(AssemblyName.GetAssemblyName(path));
    }

    public Type GetType(string typeName)
    {
      return _assembly.GetType(typeName);
    }

    public static AssemblyLoader CreateInNewDomain(string domainName, string applicationBase)
    {
        AppDomainSetup setup=new AppDomainSetup{ApplicationBase=applicationBase};
      var ad = AppDomain.CreateDomain(domainName,null,setup);

      // Loader lives in another AppDomain
      AssemblyLoader loader = (AssemblyLoader)ad.CreateInstanceAndUnwrap(
        typeof(AssemblyLoader).Assembly.FullName,
        typeof(AssemblyLoader).FullName);
      loader.Domain = ad;

      return loader;
    }

    public static void Unload(AssemblyLoader loader)
    {
      AppDomain.Unload(loader.Domain);
    }
  }

#>

Tips And Tricks:
Problem: the T4 generated file has some unexplained empty lines before the start of the text.
Solution: Remove any spaces from the end of lines. Amazingly so, some white space at the end of some of the lines were translated as empty lines in the resulting .tt.

Problem: The code is not aligned properly
Solution: Well, it should be obvious, but empty spaces before the T4 tags are translated as empty spaces in the resulting .tt file. In other words, stuff like <# ... should not be preceded by any indenting. It will make the template look a bit funny, but the resulting template will look ok. If you dislike the way the intending looks in the template, move the indent space in the tag, where it will be treated as empty space in the T4 code.