To get the latest build of T4MVC:

Go to T4MVC page on CodePlex

T4MVC build 2.5.00 brings a couple of fun new features that I’ll describe in this post.  I can’t take too much credit for them as they came from users who suggested them to me, and helped out getting the code going.

Support for multiple output files

Up until now, T4MVC.tt has always generated a single file, which is the T4MVC.cs that you see get nested under it in VS.  And normally, this is the way T4 templates work: they just generate one file.  But last week I got an email from Stuart Leeks who pointed me to a new blog post from Damien Guard that describes a nice way to get around this limitation.  All of Damien’s logic is very nicely encapsulated in a class, making it pretty easy to add to an existing T4 template without having to make significant changes.

I was going to look into getting that in T4MVC, but Stuart went ahead and did it, so I didn’t have much to do myself.  Thanks to Stuart and Damien on this one!

But first I suppose we should discuss why generating multiple files is a good thing.  Quite simply, it keeps things more organized, and makes things cleaner when working with source control.  Since T4MVC can generate a fair bit of code, it is a good candidate to use this.  Specifically, T4MVC can now generate a different output file for each controller, making things more manageable.  Note that it still generated the ‘primary’ T4MVC.cs file, which contains all the top level things that don’t belong to any specific controller.

This behavior is on by default, but can be disabled in T4MVC.settings.t4:

// If true,the template output will be split into multiple files.
bool SplitIntoMultipleFiles = true;

I debated whether to make it the default, but in the end opted for it, as I didn’t see any serious drawbacks.  But I guess if you never plan to look at or deal with the generated files in any way, it doesn’t buy you a whole lot and you may choose to turn it off.

Warning if you’re using VS2010 Beta 2: Damien’s code uses the ITextTemplatingEngineHost interface, which got moved to a new Microsoft.VisualStudio.TextTemplating.Interfaces namespace in 2010 Beta 2.  So on 2010 Beta 2, you’ll need to add one extra import line to T4MVC.tt (the second line below):

<#@ import namespace="Microsoft.VisualStudio.TextTemplating" #>
<#@ import namespace="Microsoft.VisualStudio.TextTemplating.Interfaces" #>

Support for Minified Javascript files

This one came from Matt Wicks.  Minified javascript files are alternate version of the files that makes them as small as possible, but using various strategies like removing white space.  e.g. in an MVC application’s Scripts folder, you’ll typically see both jquery-1.3.2.js and jquery-1.3.2.min.js.  Usually, you want to use the minified version at deployment time (to make your site load faster), but the regular version at development time, so you can more easily debug into it.

The new T4MVC support makes it automatic to use one vs. the other depending on the context.  T4MVC has been supporting script files for a while, letting you write:

<script src="<%= Links.Scripts.jquery_1_2_6_js %>" type="text/javascript"></script>

With this new feature, you don’t need to change anything to this line, but the token jquery_1_2_6_js will automatically point to either jquery-1.3.2.js or jquery-1.3.2.min.js depending on whether you’re running in production.  How does it know whether you’re in production?  It calls a method defined in T4MVC.settings.t4 which makes the decision.  By default, it looks at whether debugging is enabled:

    // Logic to determine if the app is running in production or dev environment
    public static bool IsProduction() { 
        return (HttpContext.Current != null && !HttpContext.Current.IsDebuggingEnabled); 
    }
But you can easily change this logic if you have a different way of determining ‘production’.