T4 error: Compiling transformation: Invalid token 'this' in class, struct, or interface member

Published Jun 30, 2010

If you have a T4 Template .tt file that throws a weird Compiling transformation: Invalid token 'this' in class, struct, or interface member error that seems to come out of nowhere, try to delete extraneous spaces.

In my case, I has copied/pasted the .tt content from a web page and I was trying to understand why it wouldn't work. I right clicked on the source, went to Advanced, chose Convert all spaces to tabs, then back to Convert all tabs to spaces. Then it worked. I guess some white spaces where not really spaces or some other formatting issue.

If you don't have the options when you right click, it might be that they are features of the Tangible T4 Editor.

Working with the T4

Published Jun 17, 2010

and has 5 comments

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.

Click to expand.

The second issue is linked to the Assembly directive. You use it somewhat like this: <#@ Assembly Name="System.Core.dll" #>. Observe the lack of a path for the dll. You don't need any if the assembly you want to use is loaded in the GAC. However, if you want to use your own library from somewhere, only rooted paths will work. Relative paths would be resolved relative to the T4 templating engine executable, not the folder in which the .tt file is placed. The solution here would be to use the Host.ResolvePath method in your code and dynamically load your assembly. Obviously that brings along its own world of hurt.

The third and most uncomprehensible for me is the issue of assembly file lock. You see, when you use an assembly, the file is locked as being in use. That also happends for the T4 engine. The issue here is that the text generation is executed in the same AppDomain as Visual Studio. So if you want to use a library that is part of your project in a T4 template, you have to either restart Visual Studio or rename the dll before recompiling that library lest you get an ugly error that the file could not be saved. The sad thing is that the T4 engine is very customizable and one can easily create their own engine host that inherits from the default one and only override the ProvideTemplatingAppDomain method and create another AppDomain so that there would be no issues, but then you have to load your templating engine somewhere, specify it in your project, etc. Give your project to someone else and they have to have the same templating engine, just for this little crap.

I've spent the day before trying to solve the problems above. Loading a library from my solution dynamically was ugly, but I only needed a type to reflect from it, so it was ok.


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

In order to get rid of the issue of assembly lock I just added a postbuild event to copy the dll to Assemblies/Work and took it from there. It is easier to rename it when the lock error appears.

I have actually tried other solutions:

I tried to load the code in another AppDomain by creating a new one and executing a callback function in it, with AppDomain.DoCallBack(delegate). Since everything in a T4 file is inside a method already, all I could do is provide it with an inline anonymous delegate. It worked, but then it would throw a SerializationException. Apparently, when trying to send a method to another AppDomain, not even the string type is serializable!
I saved all the values I needed as parameters with AppDomain.SetData and then got them inside the delegate method using AppDomain.GetData. Then I got a FileNotFoundException
I googled a bit to find out that the exception was thrown whenever I would try to execute a method in a different AppDomain. Apparently it is only supposed to be used from inside the AppDomain! Imagine that. This led me to the solution to use a custom library in which to create a class that inherits from MarshalByRefObject so that I can load it dynamically using AppDomain.Load(assemblyName) and then make a MarshalByRefObject instance execute the code I wanted.
This brings me back full circle to using a custom library
Later still, I find out that the blog entry about that FileNotFoundException was bullshit. What happened is that the AppDomain needed to be created with an AppDomainSetup parameter which specifies the ApplicationBase property as the folder in which the library you want to load is found. I still needed a way to load the class from somewhere.

A solution is to run the T4 engine from the command line only at compile time, as a prebuild task or something like that. But that means partially discarding the Visual Studio integration. At this point, creating my own app to generate files seemed not only better, but also cleaner and faster. Then I learned about the T4 class feature blocks that allow adding helper classes and methods. The only difference was the starting tag, not <#, but <#+!!

This allowed me to create a class to load the library I wanted to in another app domain, get the Type, unload the domain and then do my thing! Even better, I got to use the <#@ include #> directive to load in my templates the .ttinclude file that contained my AssemblyLoader object.

Phew! Done. If you had the same problems like me, you probably want the code. It will fill the last part of the blog post. Before you do that, you'd better read this link collection from Scott Hanselman. There are mostly from Oleg Sych's blog about T4, and some of them are slightly outdated, but you need to read them in order to understand what this is about. One of the gotchas there is that the class Template is now TextTransformation so when you get the error Compiling transformation: The type or namespace name 'Template' could not be found remember to use TextTransformation instead.

Ok, now for the code:


<#@ 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
}

As you can notice, right above the code block and below the Assembly and import directives there is an include directive that loads AssemblyLoader.ttinclude. Here is the content of the file. Notice the slightly different begin tags in it and the absence of template or output directives:


<#+
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);
    }
  }

#>

I will probably work on a custom tranformation engine that will also be encapsulated in a .ttinclude file and that would provide AppDomain separation and assembly path resolving. Later, though.

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.