The Problem

Let’s say you wanted to specify that the ViewData for this view would be an integer. Normally you would specify this in the code-behind like so:

   1: using System;

   2: using System.Web;

   3: using System.Web.Mvc;

   4:

   5: namespace MVC_Example.Views.Home

   6: {

   7:     public partial class Index : ViewPage<int>

   8:     {

   9:     }

  10: }

Since we don’t have a code-behind file though, we have to change the .aspx file’s <%@ Page %> element. Trying to set it to the following will not work:

   1: <%@ Page Language="C#" Inherits="MVC_Example.Views.Home.Index<int>" %>

The Basic Answer

The value of the Inherits attribute appears to be delivered straight to the CLR without any language specific parsing, which means we have to specify it the way the CLR wants to interpret it. I browsed around and found (here and here) some information that points out the proper way to do this:

   1: <%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage`1[ [System.Int32,mscorlib] ]" %>

WTF?

Eww, huh? The syntax is gnarly, but it gets the job done. Let’s break the syntax down to make sure you understand what is going on:

ParentType`1[ [ChildType,ChildTypeAssembly] ]

• “ParentType” is fairly obvious. This is the generic object that you want to create a reference to.
• “`1[ [" is a bit more obscure. The "`1" specifies the number of generics in this argument, which we'll come back to in a second. The double square brackets are required. A single square bracket will NOT work.
• "ChildType" is the type of object you wish to have the generic consume (what is the proper terminology here? anyone know?).
• "ChildTypeAssembly" is the name of the assembly (NOT the namespace) that contains the ChildType. All of your common value types will be located in "mscorlib".

Multiple Generic Types

Let's say ViewPage took two arguments as part of its generic declaration area (ie: ViewPage<X,Y>). It doesn't, by the way, but we'll pretend it does for the sake of argument; you may find this information useful someday.

To have two type parameters, you'll have to change the "`1" to a "`2" and add an extra "[ChildType, ChildTypeAssembly]“ reference, separated by a space. More parameters would continue to follow the same logic.

If you wanted to achieve the equivalent of ViewPage<int,string> it would look like this:

   1: System.Web.Mvc.ViewPage`2[ [System.Int32,mscorlib], [System.String,mscorlib] ]

A Generic of Generics

A more likely scenario is that you may want to have your ViewData be a generic List<T>. In this case you’ll just nest the declarations. If you wanted to pass ViewData of the type List<string> to the ViewPage it would look like:

   1: System.Web.Mvc.ViewPage`1[[System.Collections.Generic.List`1[[System.String,mscorlib]], mscorlib]]

After nearly a month of following Scott's advice on how to fix the bug, I finally grew tired of such a repetitive task and have fixed the templates. You'll find a zip file containing the fix and installation instructions at the bottom of this post. Before I get into that though, let me explain the workaround (suggested by ScottGu) that I've been using until now:

The Easy, Repetitive Workaround

The problem is that the template for pages, master pages, and user controls only include the declarative HTML file and it's code-behind. The template is missing the designer file used by Visual Studio to hide the references generated by the server controls declared in your HTML. Here is what a MVC page looks like right after creation:

You could manually create a designer class to fix this issue, but that would be a pain. Luckily Visual Studio provides us with the handy "Convert to Web Application" feature to generate the designer class for us. Simply right-click on the .ASPX (or .Master or .ASCX) and click the "Convert to Web Application" option on the context menu.

After doing so, you should see this:

Voilà! Your codebehind file for that page/control (and that page/control only) should now work as expected. Its quick and simple, but I'm sure you can imagine already the annoyance at having to do this for each and every page or control you create. That thought leads us to…

The Slightly More Complex Permanent Solution

First, an admission of guilt: I only fixed the C# templates. I apologize to any VB.Net'ers out there ahead of time.

There are four templates that must be fixed:

1. View Master Page – A master page.
2. View Page – A normal page.
3. View Content Page – A page that uses a master page.
4. View User Control – A control.

These four templates are found in two different places: the item templates folder and the item templates cache folder.

Those folders are found at: "Common7IDEItemTemplatesCSharpWeb1033" and "Common7IDEItemTemplatesCacheCSharpWeb1033" respectively (within your VS 9 root folder).

The item templates folder contains zip files which are at some point unzipped and stored in the item templates cache folder. I suppose you could just update the contents of the item templates cache folder, but I don't know if those settings would ever be written over by the item templates folder, so it is better to be safe and fix it in both places.

The contents of a typical template for pages/user controls are:

• a vtemplate file (which serves as the manifest for the rest of the items)
• an icon file
• an html file (ASPX, ASCX, etc)
• a codebehind file
• a designer file

As you can see from the screenshot below, the templates did not include a designer file.

In addition, the vtemplate file does not describe a designer file.

The fix is to add a line to the vtemplate file referencing a designer file and then add the designer file itself to the template folder/zip. The designer file should look something like:

I've gone ahead and done all this for you — well, actually for me, but you get the point. All you need to do is download the zip file from below and follow the instructions included in the readme.txt file.

MVC Template Fix.zip (50.54 kb)

Update (Dec 11): ScottGu was kind enough to post a fix for this particular problem. It is unfortunate that you have to repeat the fix for every view you add to your project, but I guess that's why it is called a CTP! ScottGu said…

There is a bug in the file template when you create a new page – and the .designer.cs file isn't generated.
To fix this, right click on the file and choose the "Convert to Web Application" menu item. This will generate the .designer.cs file that contains your control declarations. From that point on the code-behind will be kept up to date as you make changes.

Hope this helps,

Scott

Original Post: 

It may not be a popular choice, but I'm perfectly okay with in-line code in my views as long as it doesn't contain business logic. One of the developers on my project prefers tag-based views (<asp:Blah runat="server" />) and came to me yesterday with a curious issue. I've spent some of the morning investigating the issue and it does appear that there is a bug in the newly released ASP.Net MVC Framework.

The issue? Controls declared in an ASPX are not visible to that page's codebehind.

To test this hypothesis (and make sure we hadn't somehow broken our project) I started a new "ASP.Net MVC Web Application" project (note that the bug also exists for the "ASP.Net MVC Web Application and Test" project). I then opened the Views/Home/About.aspx file and added the following line:

Then I opened up the page's codebehind (Views/Home/About.aspx.cs) and added the following:

Ctrl+Shift+B to compile and bam, a build error: "The name 'myLiteral' does not exist in the current context."

I began to wonder if this was not supported by the MVC framework, but I took a look back at one of ScottGu's most recent articles, ASP.Net MVC Framework (Part 3): Passing ViewData from Controllers to Views, and saw that he references controls from the page's codebehind several times. I also tried using several controls besides the Literal to no avail.

To test what was going on, I commented out the reference in the Page_Load method, added a string declaration and put a breakpoint on it. When I ran the MVC application in debug mode and loaded the page I was able to see the "myLiteral" control reference. It appears that the reference is available at runtime but Visual Studio just is not able to see it at compile time. Odd.

For now I've told the developer to just use in-line code, but I'm well aware that many developers are loathe to do so. Thoughts? Suggestions?