In among all the excitement of new ALM features like integrated Code Review and MyWork to manage your daily workflow in the developer preview, there are, of course, a few nice new features for T4.
First of all, a naming change that’s underway. We’ve heard from you that ‘Preprocessed’ isn’t the clearest choice of name for our templates, so we’ve switched to a new naming scheme:
- Design-time templates – Templates that run in the VS IDE to produce output based directly on the template content
- Run-time templates – Templates that are preprocessed in the VS IDE to produce a class that you incorporate into your application for use at runtime. Calling a method on the class produces output based on the template content.
For the Developer Preview, you’ll see this change mostly in our documentation; the new terms will find their way into the product UI in time for Beta.
Now on to new features we’ve added in the preview:
1) Improved template inheritance for runtime templates that need access to features of the host
Previously, if you had a runtime template that declared itself as host-specific,
<#@ template hostSpecific=”true” #>
it was hard to reuse the template through inheritance cleanly. Derived templates that also declared host-specific would create a second ‘Host” member that would hide the one from the base class, giving a warning.
To address this, we’ve added a third value for host-specific, “TrueFromBase”, that makes the engine generate a host specific template, but expects the ‘Host” property to come from the base class.
We’ve also made the comments generated from runtime templates more helpful.
2) Better error processing for design-time templates
When your design-time template gets past the compile stage and starts to run the compiled code, T4 now accurately reports line numbers for any exceptions that get thrown.
Don’t forget to set debug=”true” to make sure the compiler is emitting line number information.
3) COM Service helper
For folks using host-specific templates to access VS services, there’ve been a few reports of exceptions being thrown for one or two specific services.
Typically, it turns out that these services are written in managed code, but exposed over COM and then marshaled to T4’s AppDomain over .Net Remoting. (Phew!)
This rather complex path leads to the exceptions, so we’ve included a simple extension method on IServiceProvider that you can use to get hold of those services and force them to behave properly:
public static class ServiceProviderExtensions
public static Object GetCOMService(this IServiceProvider provider, Type type)
Just call this method instead of the regular GetService() method and your COM troubles should be over.
4. Item templates now support LINQ out of the box.
We’ve updated our VS item templates, so when you add a new T4 template to your VS project, you’ll automatically get all the directives you need to use LINQ right off the bat.
<#@ assembly name=”System.Core” #>
<#@ import namespace=”System.Linq” #>
<#@ import namespace=”System.Text” #>
<#@ import namespace=”System.Collections.Generic” #>
5. Correct disposal of MEF container when T4 AppDomain recycles.
We provide a simple helper method (CompositionServices.InitializeServices() ) to set up a MEF composition container in the T4 AppDomain if you want to use VS’ MEF components from your template.
T4 has a heuristic that decides when to recycle the secondary AppDomain for design-time templates. This one is really more of a bug fix, but I’ll mention it just because not many folks know about the MEF setup helper.
The fix is that now when the AppDomain gets recycled, the MEF container is correctly Disposed.
We’ll have some more features to talk about once the Beta comes along, but in the mean time, I hope you enjoy these improvements to T4 in our Developer Preview.