Angle Bracket Percent : MVC

Passing anonymous objects to MVC views and accessing them using dynamic

davidebb — Sat, 19 Dec 2009 00:06:00 GMT

First, I’ll start with a little disclaimer: this post is not about whether using dynamic is better/worse than static typing. Instead, it’s about making it more convenient to use dynamic if you choose to go that route. Clearly, some people dislike dynamic, as you can see in the comments in that post from Phil Haack, and for the most part, all the key arguments for/against have been made.

So anyway, let’s proceed… Recently, a few people have experimented with extending their view pages from ViewPage<dynamic>. The idea is to then be able to access model data using the more convenient dynamic syntax. e.g. check out this thread on StackOverflow, as well as Phil’s post I mention above.

One limitation that people are hitting is that you can’t easily pass an anonymous object as your model, because anonymous types are internal.

What we’re trying to write

e.g. Let’s say we’re trying to write this code in the controller:

public class HomeController : Controller {
    public ActionResult Index() {
        return View(
            new {
                Message = "Welcome to ASP.NET MVC!",
                Date = DateTime.Now
            });
    }
}

Note that we’re passing an anonymous object as the model. The main reason to do this is to avoid the need to create an explicit ViewModel type. Obviously, that’s controversial, but it should be viewed more as a simpler alternative to writing

ViewData["Message"] = "Welcome to ASP.NET MVC!";
ViewData["Date"] = DateTime.Now;
return View();

And then you’d change your view to have Inherits="System.Web.Mvc.ViewPage<dynamic>", which ideally would let you write something like this:

<asp:Content ID="indexContent" ContentPlaceHolderID="MainContent" runat="server">
    <h2><%: Model.Message %></h2>
    <p>
        The date is <%: Model.Date %>
    </p>
</asp:Content>

Which is simpler than having to dig things out of the view data dictionary through string indexing.

But the default dynamic binder won’t let us!

Unfortunately, if you try to run this code, it’ll blow up with this error: Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: '<>f__AnonymousType1<string,System.DateTime>.Message' is inaccessible due to its protection level

The reason for this is that the anonymous type being passed in the controller in internal, so it can only be accessed from within the assembly in which it’s declared. Since views get compiled separately, the dynamic binder complains that it can’t go over that assembly boundary.

But if you think about it, this restriction from the dynamic binder is actually quite artificial, because if you use private reflection, nothing is stopping you from accessing those internal members (yes, it even work in Medium trust). So the default dynamic binder is going out of its way to enforce C# compilation rules (where you can’t access internal members), instead of letting you do what the CLR runtime allows.

Solution: write our own!

I’m not sure why it was designed this way, but the good news is that it’s easy to work around by writing our own custom DynamicObject which binds through private reflection! I’ve written a couple posts that make use of custom DynamicObjects (find them here), and the basic concept is the same: given the name of a property, write whatever code you want to produce its value.

Here, we’re not only going to write a custom Dynamic Object, but also a custom DynamicViewPage that uses it. And doing all this takes surprisingly little code. Here is the full implementation:

public class DynamicViewPage : ViewPage {
    // Hide the base Model property and replace it with a dynamic one
    public new dynamic Model { get; private set; }

    protected override void SetViewData(ViewDataDictionary viewData) {
        base.SetViewData(viewData);

        // Create a dynamic object that can do private reflection over the model object
        Model = new ReflectionDynamicObject() { RealObject = ViewData.Model };
    }

    class ReflectionDynamicObject : DynamicObject {
        internal object RealObject { get; set; }

        public override bool TryGetMember(GetMemberBinder binder, out object result) {
            // Get the property value
            result = RealObject.GetType().InvokeMember(
                binder.Name,
                BindingFlags.GetProperty | BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic,
                null,
                RealObject,
                null);

            // Always return true, since InvokeMember would have thrown if something went wrong
            return true;
        }
    }
}

As you can see there is not that much to it: when we need to look up a property value, we use private reflection and that’s the end of it.

And now it all works!

Once we have this, all that’s left to do is use it as our base class for the view, e.g.

<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="MvcHelpers.DynamicViewPage" %>

And we’re then able to write exactly what we wanted above in the controller and the view, without hitting any access issues.

The full VS2010 project is attached to this post.

T4MVC 2.6: MVC 2 Areas support

davidebb — Mon, 30 Nov 2009 06:51:36 GMT

To get the latest build of T4MVC:

Go to T4MVC page on CodePlex

One of MVC 2's major new features is the support for breaking up a large application into "Areas". This works by following a structure that looks like:

Root folder
- Models
- Views
- Controllers
- Areas
  - NerdDinner
    - Models
    - Views
    - Controllers
  - Blog
    - Models
    - Views
    - Controllers

So basically you still have your top level Models/Views/Controllers folders, and in addition to that you can have an arbitrary number of “Areas”, each having their own set of Models/Views/Controllers folders.

Starting with MVC 2.6, T4MVC lets you use areas in much the same way it lets you access top level items. e.g. you can now write:

<%= Html.ActionLink("Delete Dinner", MVC.NerdDinner.Dinners.Delete(Model.DinnerID))%>

Note how we referred to the controller as MVC.NerdDinner.Dinners.

Optionally, if you set IncludeAreasToken to true in the settings file, this becomes:

<%= Html.ActionLink("Delete Dinner", MVC.Areas.NerdDinner.Dinners.Delete(Model.DinnerID))%>

Lots of headaches to find a good naming pattern for Areas in T4MVC

Surprisingly, one of the things that caused the most headaches in getting this working was finding a well working naming pattern.

Here are the patterns that were on the table:

MVC.NerdDinner.Dinners
MVC.NerdDinnerArea.Dinners
MVC.Areas.NerdDinner.Dinners

#1 is the simplest and most concise, but breaks if you have a top level controller that has the same name as the area.

#2 appends ‘Area’ to the area name to solve the conflict we caused by #1. But while it solves the conflict, you end up with a slightly quirky naming scheme.

#3 uses an extra Areas token before the area name to avoid the conflict. The drawback here is that you end up with one more token, meaning one more thing to type through in intellisense.

I then polled twitter to see whether people preferred #2 or #3, and most went with the cleaner and more wordy #3.

Then Nikhil suggested using a hybrid of #1 and #2, where we only append ‘Area’ to the area name if we detect a conflict with a top level controller name. Let’s call this #4!

So I ended up supporting both #3 and #4, based on the IncludeAreasToken switch in the settings file.

But frankly, I’m considering getting rid of #3. In the twitter poll, people didn’t like #2 mostly because it’s weird to have that extra ‘Area’ suffix. But with the hybrid #4 solution, this funky name only occurs exceptionally, making it much less of an issue.

To end this post, I’d like to thank Nathan Roe for helping out putting together this change!

T4MVC now has a real home and a dedicated forum!

davidebb — Wed, 25 Nov 2009 08:09:39 GMT

Up until now, most things related to T4MVC were happening through my various blog posts about it. And while that was sort of working ok for a while, it was also less than ideal for a couple reasons.

First, there was no single place to go to in order to get information about it. You’d basically have to go through the various posts that describe the various features as they were added. And as the number of posts grew, so did the pain involved in doing that.

The second issue is that there was no good place to discuss it, ask questions and report issues. So all of those things were mostly just happening organically as comments in my various posts, which really doesn’t work so well. Blog Post comments don’t support threading, and things ended up being spread all over the place.

To simplify this mess, I created two things:

New T4MVC Home Page: http://aspnet.codeplex.com/wikipage?title=T4MVC

This page contains everything you may want to know about T4MVC: where to get it, the complete documentation, and links to other relevant places. And obviously, the idea is to keep this page up to date as new features are added.

New discussion forum: http://forums.asp.net/1215.aspx

This is a standard ASP.NET forum, much like the one used for MVC and other ASP.NET topics. If you have any questions or comments about T4MVC, this is the place to go!

Hopefully, this will help make things a little less random :)

T4MVC 2.5.01: added support for Html.RenderAction and Html.Action

davidebb — Sat, 21 Nov 2009 02:10:00 GMT

To get the latest build of T4MVC:

Go to T4MVC page on CodePlex

MVC 2 Beta introduces two nice helpers called Html.RenderAction and Html.Action. Phil Haack described them in detail on his blog, so you may want to read through that before reading this post.

Basically, they’re two additional methods that follow the standard MVC pattern of passing the controller name and action name as literal strings, and the action parameters as anonymous objects. e.g. Copying from Phil’s example, if you have an Action like this:

public ActionResult Menu(MenuOptions options) {
    return PartialView(options);
}

You can write this in your View:

<%= Html.Action("Menu", new { options = new MenuOptions { Width=400, Height=500} })%>

Note how the action name is hard coded, and the MenuOptions parameter is passed as an anonymous object. With T4MVC, you can instead write:

<%= Html.Action(MVC.Home.Menu(new MenuOptions { Width=400, Height=500})); %>

Giving you full intellisense and type checking for the controller name, action name and parameters.

Another advantage is that normally, if you use an ActionName attribute, you’ll need to pass that name instead of the action method name. Again from Phil’s blog:

[ActionName("CoolMenu")]
public ActionResult Menu(MenuOptions options) {
    return PartialView(options);
}

And you then have to pass “CoolMenu” instead of “Menu” when you make the call, which is pretty easy to get in trouble with. But with T4MVC, the fact that you use a non-default Action Name is abstracted out, so you make the exact same Html.RenderAction(MVC.Home.Menu(...)) call.

Of course, all of this is nothing new if you’re used to using T4MVC. It’s just the same pattern as we have everywhere else, applied to those couple new methods. Maybe I’m just rehashing the same old benefits of strong typing and avoiding literal strings :)

On a separate note: I fixed a small bug that happened when you used a custom ActionResult without an explicit ctor. See comments in previous post for details on the issue.

T4MVC 2.5.00 update: multiple output files and minified javascript support

davidebb — Tue, 17 Nov 2009 02:41:00 GMT

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’.

T4MVC 2.4.04 update: MVC 2 support, new settings, cleanup, fixes

davidebb — Thu, 15 Oct 2009 20:02:00 GMT

To get the latest build of T4MVC:

Go to T4MVC page on CodePlex

Though I haven’t blogged for a while about T4MVC, I’ve been making a few minor updates and only sent notification via Twitter. Now, I have a few things that are worth discussing in a little more detail. Note that you can see the complete list of changes from version to version in the readme.txt file that comes with it. BTW, I used to have all this revision information directly in the .tt file, but it was getting a little long so I moved it to the readme.

The changes described below were added between version 2.4.00 and 2.4.04.

MVC 2 Preview 2 support

The most interesting things to many people is that I just made a fix to allow T4MVC to work on MVC 2 Preview 2 apps. The reason is was not working is that the MVC team changed a number of their API’s to return MvcHtmlString instead of strings.

One challenge here is that I did not want to maintain two separate versions of T4MVC, just to account for this small difference. Instead, I ended up adding logic in T4MVC which detects which version of ASP.NET MVC your app is using, and adapts what it generates accordingly. The result is that the overall T4MVC experience is the same as before: you drop it into any MVC app and it should just work!

Detecting the version of MVC in use through the less-then-perfect VS DTE object model was a bit of a challenge in itself. In case you’re curious, here is the logic I ended up with:

var vsProject = (VSLangProj.VSProject)Project.Object;

foreach (VSLangProj.Reference r in vsProject.References) {
    if (r.Name.Equals("System.Web.Mvc", StringComparison.OrdinalIgnoreCase)) {
        return r.MajorVersion;
    }
}

The fact that I had to cast Project.Object to a VSProject was far from intuitive. But anyway, I digress, this post is not about the VS DTE model :)

So, back to MVC 2, please note that this new T4MVC does not add support for any of the new features. It simply allows it to run without blowing up, but still only supports features that existed in MVC 1. In particular, the one big obvious feature that would be worth supporting is Areas (Phil’s blog). This is something I’d definitely like to add support for when I get some cycles (unless someone else does it first! :)).

Generate cleaner code that doesn’t make various tools complain

This came as various separate changes based of issues that several people mentioned. Copying items from the revision list:

Put all the generated code in a T4MVC #region. This is useful to tell tools like ReSharper to ignore it.
Added <auto-generated /> comment to disable StyleCop in generated file
Added pragma to prevent compiler from complaining about missing Xml comments
Renamed generated classes to be CLS compliant

Generally, T4MVC is trying to be a good citizen with the various tools people are running.

New knobs in T4MVC.settings.t4

You can look at T4MVC.settings.t4 to see the list of things that are customizable. In short, and again copying from the history list, the new knobs are:

Added a setting to turn off the behavior that always keeps the template dirty
Added a setting to set the namespace that Links get generated in
Added ProcessVirtualPath method to T4MVC.settings.t4 so user can write custom logic to modify client URL's

Cleanup

I made various cleanup to the template’s logic. In particular, I greatly simplified the logic that locates the VS project that contains the T4 template, by using the FindProjectItem() method:

// Find the .tt file's ProjectItem
ProjectItem projectItem = dte.Solution.FindProjectItem(Host.TemplateFile);

Before, I was doing all kind of crazy things, mostly because I didn’t know about this method. I’m learning the VS DTE model as I go along, as I had never used it before :)

T4MVC 2.4 updates: settings file, sub view folders, ActionName support and more

davidebb — Tue, 28 Jul 2009 23:15:00 GMT

To get the latest build of T4MVC:

Go to T4MVC page on CodePlex

This post is a continuation of various previous posts on the T4MVC template for ASP.NET MVC:

I last blogged about version 2.2, and there have been a number of changes since that (you can get the full history at the top of the T4MVC.tt file). This post describes some of those changes.

T4MVC now uses a separate settings file

Previously, if you wanted to customize T4MVC, you’d have to change T4MVC.tt directly. This is fine until you want to grab the next build, and have to hand merge the changes.

Instead, it is now using a separate settings file called T4MVC.settings.t4. The idea is that you can tweak some behavior by changing this file, without changing the main file. Make sure that you copy both files when you grab 2.4 or later!

Note: it uses a .t4 extension instead of .tt, because we don’t want VS to process it directly. Instead, it’s included by the main .tt file. What’s nice is that the .t4 extension is also recognized by Clarius’ Visual T4.

Currently, it doesn’t support all that many settings, but it’s only a first step. The idea is that as more customization scenarios come up, new things will appear there. Of course, you may need some small hand merging of the settings files when you update to newer versions, but that’s a lot less painful than merging the main .tt file.

Here is what it contains in 2.4.00:

// The prefix used for things like MVC.Dinners.Name and MVC.Dinners.Delete(Model.DinnerID)
const string HelpersPrefix = "MVC";

// The folder under the project that contains the controllers
const string ControllersFolder = "Controllers";

// The folder under the project that contains the views
const string ViewsRootFolder = "Views";

// Folders containing static files for which links are generated (e.g. Links.Scripts.Map_js)
readonly string[] StaticFilesFolders = new string[] {
    "Scripts",
    "Content",
};

Support for views in sub folders

I have had a few users mention that they sometimes don’t put their views directly under Views\CtrlName, but instead put them in a subfolder. e.g. you might have Views\Dinners\Sub\Details.aspx.

Previously, T4MVC was ignoring those. Now, it finds them and makes them available using a matching hierarchy.

So when you have Views\Dinners\Sub\Details.aspx, you can refer to it as

MVC.Dinners.Views.Sub.Details

or if you’re within the Dinners controller, you can just write:

Views.Sub.Details

And this will evaluate to "Sub/Details".

Support for [ActionName] attribute

Suppose you have an action method that looks like:

public virtual ActionResult Details(int id) {

By default, the action name is just the method name: “Details”. That is, this is what normally shows up in your URLs, e.g. /Dinners/Details/2.

But sometimes, you want your action name to be different from the method name, and that’s when you would use the MVC ActionName attribute. e.g.

[ActionName("NewActionName")]
public virtual ActionResult Details(int id) {

And now your URLs start looking like /Dinners/NewActionName/2.

Except that previously, T4MVC was ignoring this attribute, causing it to still generate the old URL! Now, it correctly locates and honors the attribute.

The beauty is that T4MVC completely shields your code from those changes. Without it, you’d have written:

<%= Html.ActionLink(dinner.Title, "Details", new { id=dinner.DinnerID }) %>

And you would have had to change “Details'” to “NewActionName”. But with T4MVC, you just write:

<%= Html.ActionLink(dinner.Title, MVC.Dinners.Details(dinner.DinnerID)) %>

And it keeps on doing the right thing no matter what the ActionName is set to!

New parameter-less overload for all actions

Previously, T4MVC was only offering pseudo-action calls that had the exact same signature as the real action method. This usually works well, but in some POST scenarios, the parameters comes from the form and not the URL.

To solve this, T4MVC now always generates a parameter-less overloads. e.g. suppose your action looks like:

[AcceptVerbs(HttpVerbs.Post), Authorize]
public virtual ActionResult Edit(int id, FormCollection collection) {

Where both the id and the FormCollection are things that you don’t want to pass explicitly, you can write:

<% using (Html.BeginForm(MVC.Dinners.Edit())) { %>

So you still get the benefit of not hard coding the controller and action names (what T4MVC is all about), even though you’re not using the signature that matches your real action.

Support for placing T4MVC.tt below the root of the app

Previously, T4MVC.tt had to be at the root of the MVC web application. Some users mentioned that they preferred to have it in some other folder, like ‘Templates’. So I made a change so it can be anywhere under the project root.

Bug fixes

There are also a number of bug fixes that are not interesting enough to discuss individually. Please see the history at the top of T4MVC.tt for details.

Two ways to use T4 templates: support code vs. one-time generation

davidebb — Fri, 17 Jul 2009 10:43:06 GMT

T4 templates have proven to be useful is a whole range of scenarios, and more and more developers are finding interesting things to do with them.

For the most part, all those scenarios fall under two very distinct categories: “support code” versus one-time generation. Unlike my previous post on CodeDom vs. T4, here we’re not talking about making a choice between two competing technologies, but simply about using T4 in the way that makes sense for a given scenario.

Let’s start with a brief description of the two usage patterns:

Support code: here, a T4 template generates a file that you rarely need to look at, and you should never modify. Instead, it contains “support code” that you can code against. A great example of this is my T4MVC template.

One-time generation: here, you are executing a T4 template to generate a file that then becomes part of your project. This file can then safely be modified. The T4 template just gave you a starting point. A great example of this is the Add View dialog in ASP.NET MVC.

I purposely gave two examples that relate to ASP.NET MVC to make a point that the two scenarios are not exclusive, and can play different parts within the same application.

The rest of this post will discuss various aspects of the two scenarios in more details.

Using T4 templates to generate “Support Code”

This is the scenario that you are most likely to have encountered when you got introduced to T4 templates. It has a pretty low barrier of entry as it is directly supported by Visual Studio 2008. The general flow here is:

You add a file with a .tt extension to your VS project
VS knows about those files, so it instantly sets it up to use the ‘TextTemplatingFileGenerator’ custom tool (you can see this in the .tt file’s property grid).
Whenever you save the .tt file, the template executes, and the generated file becomes a sub-file of the .tt file.

e.g. suppose your Hello.tt file has:

<#@ Template Language="C#v3.5" #>
<#@ Output Extension=".cs" #>

public static class Hello {
    public static void SayHello() {
<# for (int i=0; i<5; i++) { #>
        System.Console.WriteLine("Hello <#= i #>");
<# } #>
    }
}

In the solution explorer, you will see:

And Hello.cs will contain:

public static class Hello {
    public static void SayHello() {
        System.Console.WriteLine("Hello 0");
        System.Console.WriteLine("Hello 1");
        System.Console.WriteLine("Hello 2");
        System.Console.WriteLine("Hello 3");
        System.Console.WriteLine("Hello 4");
    }
}

Pretty simplistic stuff as far as code generation goes, but there are some key points that need to be made about it.

First and foremost, you should never modify the generated file. You certainly can go in there and make changes, and no one will stop you. You can even run your project and your hand modified code will execute. But guess what will happen the next time you open Hello.tt and save it? It will re-execute and blow away your carefully modified Hello.cs. So resist the temptation, and don’t mess with the generated file!

That’s why I named this scenario “Support Code”. What gets generated is code that is meant to be used by you in the rest of your app. e.g. in the example above, you could simply call Hello.SayHello() from your console app’s Main.

Now you can take a look at the T4MVC template, which has 1000 lines and does pretty complex things to make it easier to write your MVC app. But in essence, it works the exact same way as this trivial example: it’s a .tt file which generates a .cs file. You rarely look at the .cs file, and you never modify it, but instead you call into the bits and pieces that it generates from your controllers and views. It will frequently regenerate as you project changes, and that’s really the whole point: it keeps itself up to date so you don’t code against stale code.

Using T4 files for one-time generation

In this scenario, our purpose is to help the user create a new file for their project by pre-generating it with some useful content instead of having them start with some generic empty file.

As mentioned above, a great example of this is the ASP.NET MVC Add View functionality. It is described in quite some detail in this post, so you may want to check it out. I’ll use this as an illustration in this section, though of course a similar technique can be applied to other domains. Here the general flow is:

You would like to generate a new View for their app
Instead of giving you a generic new view (which a regular item template would do), it asks you a bunch of questions:
- What kind of view would you like, e.g. List, Details, Edit, …
- What kind of entity is it for, e.g. Product, Customer, …
- What master page you want to use, etc…
It takes all that knowledge and feeds it into a T4 template (suing a custom T4 host; a bit more on this later), which generates the view and adds it where it belongs in your project

In both the “Support Code” scenario and here, a T4 file is used to generate another file, but from here on things become totally different. In this one-time generation scenario, the resulting file becomes a completely normal file that’s part of your project. As such, you can freely modify it without fear of it getting overwritten, since the T4 template is no longer in the picture. It was simply used to create the file to get you started. It was a “one-time” generation.

One weakness of this model is that you can’t easily rerun the template. e.g. suppose your Product class gets a new member and you want to update the view to account for it. If you hadn’t touched to previous generated view, you can certainly delete it and rerun the Add View dialog. But if you had made any modifications, you’re mostly out of luck, and probably better off updating your view by hand without help from the T4 template. In spite of this weakness, the model is still very useful to get the user quickly started with their code and guiding them towards the pit of success.

Note that I didn’t say much about exactly how the T4 template gets executed in this scenario. Unlike the “Support Code” scenario, VS is not the one doing it. Instead, you have to do some things that are a bit more involved to make it happen. I won’t go into details about how to write a custom T4 host here as it is beyond the scope of this post, and is well covered by other posts (in particular, check out Oleg Sych’s blog).

One last thing I’ll mention about this model is that the .tt file is normally not part of your project. Instead, it lives somewhere else, and only its output becomes part of your project. Well, technically, the .tt file can be in your project for easy editing, but you then have to remove the ‘TextTemplatingFileGenerator’ custom tool, because you really don’t want it to execute on its own (it would surely fail with the custom host).

Conclusion

To reemphasize what I said early on, these are not two scenarios that compete with each other and for which you must “pick a side”. They are just two completely different ways of making use of T4 files. Both are being used successfully in various projects, and they can live together happily ever after :)

T4MVC 2.2 update: Routing, Forms, DI container, fixes

davidebb — Tue, 30 Jun 2009 23:42:00 GMT

To get the latest build of T4MVC:

Go to T4MVC home page

This post is a continuation of various recent posts, most notably:

First, I’d like to thank all those who are using the MVC T4 template and sent me suggestions and bug reports. Most issues have been addressed, and most suggestions have been integrated. I’m up to the 8th CodePlex drop, and it’s only been a week! You can see the history of changes at the top of the .tt file.

Frankly, when I started playing with this, I just thought it’d be a fun thing to spend the afternoon on. Instead, I have probably spent close to half my time working on it in the last week. And I do have other things to work on! :) But it’s been a lot of fun, so no regrets!

I’m not going to detail every change since the last blog post, since many are bug fixes that are not particularly exciting (though they help make the thing work!). Instead, I’ll just focus on a few new key areas.

Strongly typed support for MapRoute

This is similar to the RedirectToAction/ActionLink support, but applied to route creation. The original Nerd Dinner routes look like this:

routes.MapRoute(
    "UpcomingDinners", 
    "Dinners/Page/{page}", 
    new { controller = "Dinners", action = "Index" }
);

routes.MapRoute(
    "Default",
    "{controller}/{action}/{id}",
    new { controller = "Home", action = "Index", id = "" }
);

The ‘defaults’ line of each route is what we’re trying to fix. It makes heavy use of anonymous objects and literal strings, which should be avoided whenever possible. If your controller or action name change, you won’t easily catch it.

Previous version of T4MVC let you change that line to:

new { controller=MVC.Dinners.Name, action=MVC.Dinners.Actions.Index }

This fixes the issue for the most part, but it’s a bit wordy and doesn’t support refactoring. Now, the latest version of T4MVC lets you change those routes to:

routes.MapRoute(
    "UpcomingDinners", 
    "Dinners/Page/{page}", 
    MVC.Dinners.Index(null)
);

routes.MapRoute(
    "Default",
    "{controller}/{action}/{id}",
    MVC.Home.Index(),
    new { id = "" }
);

Note how we are now pointing at the action by simply making a call to it (though it’s a pseudo-call, and your action method won’t actually be called).

Also note that in the second route, we’re still using an anonymous object for the ‘id’. This is because even though the route expects an id, the default Action method (HomeController.Index()) doesn’t take one. You could get around this by adding a ‘string id’ param to HomeController.Index() and ignoring it in the method. You could then write MVC.Home.Index(null) in the route and avoid all anonymous objects.

BeginForm support

This came courtesy of Michael Hart. Essentially, it’s the same support as ActionLink() but for the BeginForm() method. But note that because form posts typically pass most of the data via the form and not the URL, BeginForm() is trickier to use correctly than the other methods.

Here is how you might use this:

using (Html.BeginForm(MVC.Account.LogOn(), FormMethod.Post)) { ... }

Or if the action method takes parameters, you would pass them in the call. However, when you do this you need to make sure that you aren’t also trying to pass those same parameters via the form (e.g. using a text box).

Generally, the rule of thumb is that this support works well when you’re dealing with forms where the Action method signature exactly matches the form URL.

Support for Dependency Injection containers

Though this is a bug fix rather than a new feature, I’ll mention it because it affected several people and had me puzzled for a while.

The root of the problem is that T4MVC generate new constructors for the controllers, and that DI containers use a somewhat arbitrary algorithm to decide what constructor to use. And in those users’ cases, they ended up calling the new constructor generated by T4MVC, messing things up badly.

The fix was simply to change the generated constructor to be protected, to prevent DI containers from using it. Since T4MVC only uses it when it instantiates the controller derived class, protected works fine.

Well, I should note that I haven’t actually verified that the fix addresses the issue, but I’m sure those users will tell me if it doesn’t! :)

The MVC T4 template is now up on CodePlex, and it does change your code a bit

davidebb — Fri, 26 Jun 2009 17:23:00 GMT

Short version: the MVC T4 template (now named T4MVC) is now available on CodePlex, as one of the downloads in the ASP.NET MVC v1.0 Source page.

Go to T4MVC home page

Poll verdict: it’s ok for T4MVC to make small changes

Yesterday, I posted asking how people felt about having the template modify their code in small ways. Thanks to all those who commented! The fact that Scott Hanselman blogged it certainly helped get traffic there :)

The majority of people thought that it was fine as long as

It’s just those small changes: make classes partial and action methods virtual. Don’t mess with ‘real’ code!
It asks for permission, or at least tells you what it’s doing

I started looking for a way to pop up a Yes/No dialog, but ended up going with a slightly different approach: T4MVC adds a warning line for every item it modifies. e.g. when you run it, you might see these in the warnings area:

Running transformation: T4MVC.tt changed the class DinnersController to be partial
Running transformation: T4MVC.tt changed the action method DinnersController.Index to be virtual

Some people were worried about version control. I tried using TFS, and everything worked fine. i.e. when the template modifies files, VS automatically checks them out. We’ll need to see how that works for folks using different systems.

What’s new in this version?

The template on CodePlex (version 2.0.01 at the top of the file) supports what I described in my previous post, plus some new goodies.

Refactoring support for action methods

One of the big issues before was the lack of refactoring support. e.g. when you wrote:

return RedirectToAction(MVC.Dinners.Details(dinner.DinnerID));

This looked like a call to you Details controller action, but it was actually an unrelated method by the same name. Hence, if you renamed your action method and refactored, this call was not modified. It would give a compile error, and had to be hand fixed.

Now the template takes a drastically different approach:

It extends the controller class
It overrides the action method (hence the need for it to be virtual!)
The override never calls the base (that would be very wrong), but instead returns a special ActionResult which captures the call (controller name, action name, parameter value).
The template emit a new RedirectToAction (or ActionLink, …) overload which understands this special ActionResults, and turns the call data into a ‘regular’ RedirectToAction call.

Pretty tricky stuff, but it works quite well. Some credit to my manager Mike Montwill for coming up with this crazy idea!

Because the method you call is an override of the real action method, refactoring works perfectly. Also, if you F12 (Go To Definition) on the call, it’ll go straight to your Action method and not some generated code.

Unfortunately, Visual Studio doesn’t support refactoring in Views, but 3^rd party tools like Resharper and CodeRush do, so if you use one of those, you’re fully covered.

The T4 file automatically runs whenever you build

This was the other big painful issue I was up against: every time you made a change to your code that affect the generated code (e.g. new Action, new View, …), you had to manually save the .tt file to cause it to regenerate the new helper code.

This was a really hard issue, and I must warn you that what I ended up with is more of a workaround than a fix. However, it is pretty effective, so until we find a better solution, it’ll have to do.

Here is how it works. Warning: reading this has been shown to cause headaches in lab rats:

As part of its execution, the T4 file finds itself in the VS project system (it had to do that anyway)
It then runs the magic instruction ‘projectItem.Document.Saved = false;’, which causes it to become dirty.
It then proceeds to do its code generation, leaving its file in an unsaved state
Next time you Build your project, VS first saves all the files
This causes the ‘dirty’ T4 template to execute, mark itself as dirty again, and redo its code generation
You get the idea! If you feel like the lab rats, this may help.

One caveat is that you have to initiate the cycle by opening and saving T4MVC.tt once. After you do that, you don’t need to worry about it.

Support for strongly typed links to static resources

Credit for this idea goes to Jaco Pretorius, who blogged something similar.

The template generates static helpers for your content files and script files. So instead of writing:

<img src="/Content/nerd.jpg" />

You can now write:

<img src="<%= Links.Content.nerd_jpg %>" />

Likewise, instead of

<script src="/Scripts/Map.js" type="text/javascript"></script>

You can write:

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

The obvious benefit is that you’ll get a compile error if you ever move or rename your static resource, so you’ll catch it earlier.

Another benefit is that you get a more versatile reference. When you write src="/Content/nerd.jpg", your app will only work when it’s deployed at the root of the site. But when you use the helper, it executes some server side logic that makes sure your reference is correct wherever your site is rooted. It does this by calling VirtualPathUtility.ToAbsolute("~/Content/nerd.jpg").

One unfortunate thing is that for some reason, VS doesn’t support intellisense in the view for parameter values. As a workaround, you can type it outside of the tag to get intellisense and then copy it there.

More consistent short form to refer to a View from a Controller class

Previously, it supported an _ based short form inside the controller:

return View(View_InvalidOwner);

That was a bit ugly. Now, the short form is:

return View(Views.InvalidOwner);

Here, Views.InvalidOwner is the same as MVC.Dinners.Views.InvalidOwner, but can be shortened because ‘Views’ is a property on the controller.

Many bug fixes

I also fixed a number of bugs that people reported and that I ran into myself, e.g.

It supports controllers that are in sub-folders of the Controllers folder and not directly in there
It works better with nested solution folder

I’m sure there are still quite a few little bugs, and we’ll work through them as we encounter them

Mind if my MVC T4 template changes your code a bit?

davidebb — Thu, 25 Jun 2009 09:45:00 GMT

Update: Please see this post for what came out of this ‘poll’, and for a pointer to the newest T4 template on CodePlex.

When working on my MVC T4 template, I was not able to use reflection to discover the Controllers and Actions, because the code that the template generates is itself in the same assembly as the controllers. So that causes a bit of a chicken and egg problem.

Instead, I had to get out of my element and learn something I was not familiar with: the Visual Studio File Code Model API. It’s very different from using reflection, because instead of working at the assembly level, you work at the source file level.

You have to first locate the source file you want to look into. You can then ask for the namespaces that it contains, and the classes that they contain, and finally the various members in those classes. To be honest, I find this API quite ugly. It’s a COM interop thing with a horrible object model that looks like it grew organically from version to version rather than having been designed with usability in mind. So all in all, I used it because I had to, but the whole time I was wishing I could use reflection instead.

But then I made an important realization. Ugly as it is, this object model supports something that would never be possible with reflection: it lets me modify the source code!

If you look at my previous post, I wrote “But to make things even more useful in the controller, you can let the T4 template generate new members directly into your controller class. To allow this, you just need to make you controller partial”. And I have logic in the template that tests this, and does extra generation if it is partial, e.g.

if (type.ClassKind == vsCMClassKind.vsCMClassKindPartialClass) { ... }

But instead, I have now realized that I can turn this check into an assignment, and change the class to partial if it isn’t already!

type.ClassKind = vsCMClassKind.vsCMClassKindPartialClass;

Likewise, I have scenarios where I can do cool things if the Controller actions are virtual, and I can just change them to be with a simple line:

method.CanOverride = true;

To be clear, those statements actually modify the original source file, the one that you wrote. While this is certainly powerful and opens up some new doors, it also raises a big question which is the main purpose of this post:

Do you mind if the T4 template makes these small changes to your code?

We’re only talking about pretty harmless things (making classes partial and methods virtual), but I know developers can get nervous if even small changes magically happen in their source files.

So please tell me how you feel about this, e.g. is it more:

It’s harmless, go for it if it makes the template more useful
Undecided. I don’t really like it, but maybe I’ll put up with it.
No way I’ll use this template if it messes with my files in any way. I may even sue you!

Tell me where you stand, and please don't sue me.

A new and improved ASP.NET MVC T4 template

davidebb — Wed, 17 Jun 2009 18:34:00 GMT

Update: Please read this post for the newest and greatest.

A couple weeks ago, I blogged about using a Build provider and CodeDom to generate strongly typed MVC helpers at runtime. I followed up a few days later with another version that used T4 templates instead, making it easier to customize.

And now I’m back with yet another post on this topic, but this time with a much simpler and improved approach! The big difference is that I’m now doing the generation at design time instead of runtime. As you will see, this has a lot of advantages.

Drawbacks of the previous runtime approach

Before we go and re-invent the wheel, let’s discuss what the issues with the runtime T4 approach were, and how this is solved by this new approach.

Complex configuration: to enable the runtime template, you had to add a DLL to your bin, modify two web.config files, and drop two T4 files in different places. Not super hard, but also not completely trivial. By contrast, with this new approach you just drop one .tt file at the root of your app, and that’s basically it.

No partial trust support: because it was processing T4 files at runtime, it needed full trust to run. Not to mention the fact that using T4 at runtime is not really supported! But now, by doing it at design time, this becomes a non-issue.

Only works for Views: because only the Views are compiled at runtime, the helpers were only usable there, and the controllers were left out (since they’re built at design time). With this new approach, Controllers get some love too, because the code generated by the template lives in the same assembly as the controllers!

Let’s try the new T4 template with the Nerd Dinner app

Let’s jump right in and see this new template in action! We’ll be using the Nerd Dinner app as a test app to try it on. So to get started, go to http://nerddinner.codeplex.com/, download the app and open it in Visual Studio 2008 SP1.

Then, simply drag the T4 template (the latest one is on CodePlex) into the root of the NerdDinner project in VS. And that’s it, you’re ready to go and use the generated helpers!

Once you’ve dragged the template, you should see this in your solution explorer:

Note how a .cs file was instantly generated from it. It contains all the cool helpers we’ll be using! Now let’s take a look at what those helpers let us do.

Using View Name constants

Open the file Views\Dinners\Edit.aspx. It contains:

<% Html.RenderPartial("DinnerForm"); %>

This ugly “DinnerForm” literal string needs to go! Instead, you can now write:

<% Html.RenderPartial(MVC.Dinners.Views.DinnerForm); %>

Though it’s wordier, note that you get full intellisense when typing it.

ActionLink helpers

Now open Views\Dinners\EditAndDeleteLinks.ascx, where you’ll see:

<%= Html.ActionLink("Delete Dinner", "Delete", new { id = Model.DinnerID })%>

Here we not only have a hard coded Action Name (“Delete”), but we also have the parameter name ‘id’. Even though it doesn’t look like a literal string, it very much is one in disguise. Don’t let those anonymous objects fool you!

But with our cool T4 helpers, you can now change it to:

<%= Html.ActionLink("Delete Dinner", MVC.Dinners.Delete(Model.DinnerID))%>

Basically, we got rid of the two unwanted literal strings (“Delete” and “Id”), and replaced them by a very natural looking method call to the controller action. Of course, this is not really calling the controller action, which would be very wrong here. But it’s capturing the essence of method call, and turning it into the right route values. And again, you get full intellisense:

By the way, feel free to press F12 on this Delete() method call, and you’ll see exactly how it is defined in the generated .cs file. The T4 template doesn’t keep any secrets from you!

Likewise, the same thing works for Ajax.ActionLink. In Views\Dinners\RSVPStatus.ascx, change:

<%= Ajax.ActionLink( "RSVP for this event",
                     "Register", "RSVP",
                     new { id=Model.DinnerID }, 
                     new AjaxOptions { UpdateTargetId="rsvpmsg", OnSuccess="AnimateRSVPMessage" }) %>

to just:

<%= Ajax.ActionLink( "RSVP for this event",
                     MVC.RSVP.Register(Model.DinnerID),
                     new AjaxOptions { UpdateTargetId="rsvpmsg", OnSuccess="AnimateRSVPMessage" }) %>

You can also do the same thing for Url.Action().

Even the controller gets a piece of the action

As mentioned earlier, Controllers are no longer left out with this approach.

e.g. in Controllers\DinnersController.cs, you can replace

return View("InvalidOwner");

return View(MVC.Dinners.Views.InvalidOwner);

But to make things even more useful in the controller, you can let the T4 template generate new members directly into your controller class. To allow this, you just need to make you controller partial, e.g.

public partial class DinnersController : Controller {

Note: you now need to tell the T4 template to regenerate its code, by simply opening the .tt file and saving it. I know, it would ideally be automatic, but I haven’t found a great way to do this yet.

After you do this, you can replace the above statement by the more concise:

return View(View_InvalidOwner);

You also get to do some cool things like we did in the Views. e.g. you can replace:

return RedirectToAction("Details", new { id = dinner.DinnerID });

return RedirectToAction(MVC.Dinners.Details(dinner.DinnerID));

How does the T4 template work?

The previous runtime-based T4 template was using reflection to learn about your controllers and actions. But now that it runs at design time, it can’t rely on the assembly already being built, because the code it generates is part of that very assembly (yes, a chicken and egg problem of sort).

So I had to find an alternative. Unfortunately, I was totally out of my element, because my expertise is in the runtime ASP.NET compilation system, while I couldn’t make use of any of it here!

Luckily, I connected with a few knowledgeable folks who gave me some good pointers. I ended up using the VS File Code Model API. It’s an absolutely horrible API (it’s COM interop based), but I had to make the best of it.

The hard part is that it doesn’t let you do simple things that are easy using reflection. e.g. you can’t easily find all the controllers in your project assembly. Instead, you have to ask it to give you the code model for a given source file, and in there you can discover the namespaces, types and methods.

So in order to make this work without having to look at all the files in the projects (which would be quite slow, since it’s a slow API), I made an assumption that the Controller source files would be in the Controllers folder, which is where they normally are.

As for the view, I had to write logic that enumerates the files in the Views folder to discover the available views.

All in all, it’s fairly complex and messy code, which hopefully others won’t have to rewrite from scratch. Just open the .tt file to look at it, it’s all in there!

In addition to looking at the .tt file, I encourage you to look at the generated .cs file, which will show you all the helpers for your particular project.

Known issues

T4 file must be saved to regenerate the code

This was briefly mentioned above. The T4 generation is done by VS because there is a custom tool associated with it (the tool is called TextTemplatingFileGenerator – you can see it in the properties). But VS only runs the file generator when the .tt file changes. So when you make code changes that would affect the generated code (e.g. add a new Controller), you need to explicitly resave the .tt file to update the generated code. As an alternative, you can right click on the .tt file and choose “Run Custom Tool”, though that’s not much easier.

Potentially, we could try doing something that reruns the generation as part of a build action or something like that. I just haven’t had time to play around with this. Let me know if you find a good solution to this.

No refactoring support

This was also the case with the previous template, but it is worth pointing out. Because all the code is generated by the T4 template, that code is not directly connected to the code it relates to.

e.g. the MVC.Dinners.Delete() generated method results from the DinnersController.Delete() method, but they are not connected in a way that the refactoring engine can deal with. So if you rename DinnersController.Delete() to DinnersController.Delete2(), MVC.Dinners.Delete() won’t be refactored to MVC.Dinners.Delete2().

Of course, if you resave the .tt file, it will generate a MVC.Dinners.Delete2() method instead of MVC.Dinners.Delete(), but places in your code that call MVC.Dinners.Delete() won’t be renamed to Delete2.

While certainly a limitation, it is still way superior to what it replaces (literal strings), because it gives you both intellisense and compile time check. But it’s just not able to take that last step that allows refactoring to work.

It is worth noting that using Lamda expression based helpers instead of T4 generation does solve this refactoring issue, but it comes with a price: less natural syntax, and performance issues.

Final words

It has been pretty interesting for me to explore those various alternative to solve this MVC strongly typed helper issue. Though I started out feeling good about the runtime approach, I’m now pretty sold on this new design time approach being the way to go.

I’d be interested in hearing what others think, and about possible future directions where we can take this.

A T4 based approach to creating ASP.NET MVC strongly typed helpers

davidebb — Fri, 05 Jun 2009 09:52:00 GMT

Update: Please see this newer post for the latest and greatest MVC T4 template

Earlier this week, I wrote a post on using a BuildProvider to create ActionLink helpers. That approach was using CodeDom to generate the code, and there was quite some user interest in it (and Phil blogged it, which helped!).

Then yesterday, I wrote a post on the Pros and Cons of using CodeDom vs T4 templates for source code generation. They are drastically different approaches, and while both have their strengths, T4 has definitely been getting more buzz lately.

The logical follow-up to those two posts is a discussion on using T4 templates to generate MVC strongly typed helpers. The general idea here is to use the existing ASP.NET extensibility points (BuildProvider and ControlBuilder), but rely on T4 templates to produce code instead of CodeDom. Hence, I called the helper library AspNetT4Bridge (I’m really good at naming things!).

As far as I know, this is the first time that T4 templates are executed dynamically inside an ASP.NET application, so let’s view this as an experiment, which has really not been put to the test yet. But it is certainly an exciting approach, so let’s see where it takes us!

What scenarios are we enabling

Before we get too far into the technical details, let’s look at the various MVC scenarios that this is enabling. But the great thing to keep in mind is that since T4 templates are so flexible, it is very easy to tweak the generated code or add additional scenarios. Hence it is best to view those scenarios as examples of the type of things that you can achieve with this model, rather than as a final end result.

ActionLink helpers

First, we have the same scenario that my previous post covered, except that we’re now using T4 instead of CodeDom. Instead of writing:

<%= Html.ActionLink("Edit", "Edit", new { id = item.ID })%>

You can write the more strongly typed (here, ‘Test’ is the name of the controller):

<%= Html.ActionLinkToTestEdit("Edit", item.ID) %>

And note that you get full intellisense in VS for those helpers!

Action Url helpers

This is similar to the previous section, except it covers the case where you need to generate raw URL’s rather than HTML <a> tags. Instead of writing:

<%= Url.Action("Edit", new { id = item.ID }) %>

You can write:

<%= Url.UrlToTestEdit(item.ID) %>

Constants for View Names

That’s another case where you often end up hard coding view names as literal string, e.g.

<% Html.RenderPartial("LogOnUserControl"); %>

With the generated helpers, you get to write:

<% Html.RenderPartial(Views.Shared.LogOnUserControl); %>

And again, you get full intellisense:

Rendering helpers for strongly typed views

Assume you are using a strongly typed view. You might write something like this (which is what the View wizard generates by default):

<label for="Name">Name:</label>
<%= Html.TextBox("Name", Model.Name) %>
<%= Html.ValidationMessage("Name", "*") %>

With the helpers, you can instead write:

<%= ViewModel.Name.Label() %>
<%= ViewModel.Name.TextBox() %>
<%= ViewModel.Name.Validation() %>

Here ViewModel is some name I came up with (well, Fowler did!) as the class that holds the helpers. There may be better names for it!

Note that the helpers can be smart about what they offer based on the data type. e.g. for a boolean field, you typically want a check box instead of a text box, and the helpers account for this:

What do you need to do to enable this in your MVC app?

There are five relatively straightforward steps you need to take to enable this.

1. Copy AspNetT4Bridge.dll into the bin folder of your app (you’ll get it by building the attached sample).

2. In the web.config file at the root of your app, register the BuildProvider for .tt files

    <compilation>
      ...
      <buildProviders>
        <add extension=".tt" type="AspNetT4Bridge.AspNetT4BridgeBuildProvider"/>
      </buildProviders>
    </compilation>

3. In the web.config in the Views folder (which you didn’t know existed, did you?), change the pageParserFilterType as follows:

pageParserFilterType="AspNetT4Bridge.Mvc.ViewTypeParserFilter"

4. Copy the Templates and App_Code folders (each containing a .tt file) from the attached sample app to the root of your app. In VS, blank out the Custom Tool for the .tt files if you see it set to TextTemplatingFileGenerator (see this post for some details on this).

5. If you have any strongly typed views (i.e. views the inherit ViewPage<T> and not just ViewPage), you need to change the Inherits attribute from System.Web.Mvc.ViewPage<...> to AspNetT4Bridge.Mvc.ViewPage<...>. I know that’s a bit ugly, and we can think of ways to clean that up later.

So what about those T4 templates?

This post is supposed to be about using T4 templates, and so far we haven’t said a whole lot about them. They are certainly the magic piece that makes all this work. We are actually using two different .tt files, which cover two distinct scenarios:

Top level code

This applies to generated code that every page is referencing, and is used for the first three scenarios above (Action Links, Urls and View name constants). The T4 file that does this is App_Code\StrongTypedLinkExtensions.tt.

As an aside, many people have a misconception that App_Code is just for web sites and not for web apps. However, while it is rarely used, is is fully available. It’s built with a reference to the bin assemblies, and all pages are built to a reference to it.

The way we make App_Code work with T4 templates is that we have a BuildProvider registered for the .tt extension. This BuildProvider uses its own ITextTemplatingEngineHost in order to process the T4 templates into source code. It then uses a CodeDom CodeSnippetCompileUnit to wrap this code into something CodeDom understands. That’s why I called this AspNetT4Bridge, as it really bridges the CodeDom world of ASP.NET with the T4 world. Fine, you come up with a better name! :)

Look for this logic in AspNetT4BridgeBuildProvider.cs.

Page level code

This applies to code that is specific to a given page, and that we just want to inject in there. This is what’s uses for the view helpers like ViewModel.Name.TextBox() described above. The T4 file that does this is Templates\MvcHtmlRenderHelpers.tt.

This works by using a ControlBuilder and its ProcessGeneratedCode method, which I discussed in a previous post. The situation is similar to the App_Code case: we need to come up with some source code, we use T4 to generate it, and we wrap it in a CodeDom construct (in this case it’s a CodeSnippetTypeMember, because the code goes inside the class).

Look for this logic in T4CodeGenerator.cs.

But what the heck is in those T4 templates?

So I’ve talked about how they get hooked up and executed, but still haven’t said a word about what’s in them. Well, I told you where they are, so go ahead and take a look! e.g. check out App_Code\StrongTypedLinkExtensions.tt.

There is nothing really hard about how it works, but the mix of generator code and generated code certainly makes it confusing at first. Do yourself a favor and install the free Clarius Community T4 editor. It doesn’t do a whole lot, but the fact that it shows the two types of code (generator and generated) in different color goes a long way to make things clearer.

The way the Action Links and Url helpers are generated is fairly straightforward:

It gets the list of referenced assemblies from the Host
It uses reflection to figure out what types are controllers
For each controllers, it finds that Action methods
For each Action method, it generates both an ActionLine and a Url helper, custom made for that action method (hence strongly typed).

The View Name Constant helpers are also fairly simple. They just look at what directories and files are under the Views folder, and generate constants accordingly. I’ll show this part here as an example:

namespace Views {
<#
var viewsDir = HostingEnvironment.VirtualPathProvider.GetDirectory("~/Views");
    foreach (VirtualDirectory dir in viewsDir.Directories) {
#>
    public static class <#= dir.Name #> {
<#      foreach (VirtualFile file in dir.Files) {
            string viewName = Path.GetFileNameWithoutExtension(file.Name);
#>
        public const string <#= viewName #> = "<#= viewName #>";
<#      } #>
    }
    
<#  } #>
}

Go ahead, try changing them!

One of the big reason to use T4 over CodeDom for this code generation is to not ‘lock’ the kind of code that get generated into a binary. Instead, you can very easily tweak it, remove things you don’t care about, and generate entirely new things. All this really takes is an understanding of <# #> and <#= #> blocks, which is pretty easy when you already know how <% %> and <%= %> blocks work, since they’re pretty much the same thing!

Final thoughts

So here we are, dynamically executing T4 templates at runtime in an ASP.NET app. One big caveat that I mentioned in my previous post is that you’re not really supposed to do that! Copying from there:

CodeDom is part of the framework, while T4 is not. That means that if you need to dynamically do this at runtime (as opposed to within VS), then T4 is not really an option. Technically, it is possible to use it at runtime outside VS, but you either have to run on a machine with VS installed, or you have to copy Microsoft.VisualStudio.TextTemplating.dll into your project (which works, but is not officially supported – hopefully it will be at some point!).

So I wrote that it wasn’t an option, and next thing I blog about doing it. What’s the deal? Well, there are some things that are changing in VS 2010 that will help. In particular, they are adding the concept of preprocessing T4 templates, while today you can only fully process them all at once. With preprocessing, we’ll be able to:

Let VS preprocess the T4 templates into some intermediate source code (that itself doesn’t requite the T4 runtime.
Run this code at ASP.NET runtime to generate the code we care about and add it to the compilation (e.g. in App_Code as above). This takes no dependency on the T4 runtime.

Another caveat I need to mention is that T4 templates can’t be fully executed in medium trust (because they need to compile code). However, with the VS 2010 changes, that will no longer be an issue.

So while in the short term, we are breaking the rules a bit by doing this and there are some tough edges, it demonstrates some very useful concepts that can be fully supported later.

And if all else fails, I had a lot of fun playing with it all!

A BuildProvider to simplify your ASP.NET MVC Action Links

davidebb — Tue, 02 Jun 2009 04:41:00 GMT

Update: Please see this newer post for the latest and greatest MVC T4 template

One downside of using Html.ActionLink in your views is that it is late bound. e.g. say you write something like this:

<%= Html.ActionLink("Home", "Index", "Home")%>

The second parameter is the Action name, and the third is the Controller name. Note how they are both specified as plain strings. This means that if you rename either your Controller or Action, you will not catch the issue until you actually run your code and try to click on the link.

Now let’s take the case where you Action takes parameters, e.g.:

public ActionResult Test(int id, string name) {
    return View();
}

Now your ActionLink calls looks something like this:

<%= Html.ActionLink("Test Link", "Test", "Home", new { id = 17, name = "David" }, null) %>

So in addition to the Controller and Action names changing, you are vulnerable to the parameter names changing, which again you won’t easily catch until runtime.

One approach to solving this is to rely on Lambda expressions to achieve strong typing (and hence compile time check). The MVC Futures project demonstrates this approach. It certainly has merits, but the syntax of Lambda expressions in not super natural to most.

Here, I’m exploring an alternative approach that uses an ASP.NET BuildProvider to generate friendlier strongly typed helpers. With those helpers, the two calls below become simply:

<%= Html.ActionLinkToHomeIndex("Home")%>
<%= Html.ActionLinkToHomeTest("Test Link", 17, "David")%>

Not only is this more concise, but it doesn’t hard code any of the problematic strings discussed above: the Controller and Action names, and the parameter names.

Steps to enable the ActionLink helpers in your MVC app

You can easily integrate these helpers in any ASP.NET MVC app by following three steps:

1. First, add a reference to MvcActionLinkHelper.dll in your app (build the project in the zip file attached to this post to get it)

2. Then, register the build provider in web.config. Add the following lines in the <compilation> section:

      <buildProviders>
        <add extension=".actions" type="MvcActionLinkHelper.MvcActionLinkBuildProvider" />
      </buildProviders>

3. The third step is a little funky, but still easy. You need to create an App_Code folder in your app, and add a file with the .actions extension in it. It doesn’t matter what’s in the file, or what its full name is. e.g. add an empty file named App_Code/generate.actions. This file is used to trigger the BuildProvider.

How does it all work?

I included all the sources in the zip, so feel free to look and debug through it to see how it works. In a nutshell:

When the first request is made at runtime, ASP.NET needs to build the App_Code assembly
It finds our .actions file, which triggers the registered BuildProvider
The BuildProvider goes through all the reference assemblies and looks for Controller classes
It then generates a static class with extension methods for each action
Since every aspx page is built with a reference to the App_Code assembly, all the views are able to use the generated helpers.

Where is this going?

At this point, this is just a quick proof of concept. There are certainly other areas of MVC where the same idea can be applied. e.g. currently it only covers Html.ActionLink, but could equally cover Url.Action(), or HTML form helpers (standard and AJAX).

Please send feedback whether you find this direction interesting as an alternative to the Lambda expression approach.