Eilon Lipton's Blog

Migrating ASP.NET MVC 2 applications to ASP.NET MVC 3 Preview 1

Eilon — Wed, 28 Jul 2010 17:34:00 GMT

ASP.NET MVC 3 Preview 1 has just been released! More info on ScottGu's blog.

I just finished up a preview of my ASP.NET MVC application conversion tool to support conversions from ASP.NET MVC 2 to ASP.NET MVC 3.

The previous version of the app that converted from ASP.NET MVC 1.0 to ASP.NET MVC 2 is available here.

Download

The app is a single executable: Download MvcAppConverter-MVC3Preview1.zip (256 KB).

Usage

The only requirement for this tool is that you have .NET Framework 4 on the machine. You do not need to have Visual Studio or ASP.NET MVC installed (unless you want to open your project!). Even though the tool performs an automatic backup of your solution it is recommended that you perform a manual backup of your solution as well.

To convert an ASP.NET MVC 2 project built with Visual Studio 2010 to an ASP.NET MVC 3 project in Visual Studio 2010 perform these steps:
- Launch the converter
- Select the solution
- Click the “Convert” button
To convert an ASP.NET MVC 2 project built with Visual Studio 2008 to an ASP.NET MVC 2 project in Visual Studio 2010:
- Open the project in Visual Studio 2010 to convert the solution and project file formats from VS2008 to VS2010
- Upgrade the .NET Framework target version of each project to .NET Framework 4 because ASP.NET MVC 3 is compatible with only .NET Framework 4
- Launch the converter
- Select the solution
- Click the “Convert” button

What it can do

Open up ASP.NET MVC 2 projects from Visual Studio 2010 (no other versions of ASP.NET MVC or Visual Studio are supported)
Create a full backup of your solution’s folder
For every VB or C# project that has a reference to System.Web.Mvc.dll it will (this includes ASP.NET MVC web application projects as well as ASP.NET MVC test projects):

Update references to ASP.NET MVC 2

For every VB or C# ASP.NET MVC Web Application it will:

Change the project type to an ASP.NET MVC 3 project
Update the root ~/web.config references to ASP.NET MVC 3
Update the root ~/web.config to have a binding redirect from ASP.NET MVC 2 to ASP.NET MVC 3
Update the ~/Views/web.config references to ASP.NET MVC 3

Add or update the JavaScript files (add jQuery, add jQuery.Validate, add Microsoft AJAX, add/update Microsoft MVC AJAX, add Microsoft MVC Validation adapter)
Unknown project types or project types that have nothing to do with ASP.NET MVC will not be updated

What it can’t do

It cannot convert projects build with Visual Studio 2008 or with .NET Framework 3.5.
It can have issues if your solution contains projects that are not located under the solution directory.
If you are using a source control system it might have problems overwriting files. It is recommended that before converting you check out all files from the source control system.
It cannot change code in the application that might need to be changed due to breaking changes between ASP.NET MVC 2 and ASP.NET MVC 3.
The release notes include manual steps to upgrade your application.

Feedback, Please!

If you need to convert a project to ASP.NET MVC 3 please try out this application and hopefully you’re good to go. If you spot any bugs or features that don’t work leave a comment here and I will try to address these issues in an updated release.

Other Resources

There are already a bunch of blog posts, walkthroughs, and even videos on the new preview, so check them out:

ScottGu’s introduction blog post: Introducing ASP.NET MVC 3 (Preview 1)
Phil Haack’s announcement: ASP.NET MVC 3 Preview 1 Released
Scott Hanselman’s Hanselminutes with Phil: <ASP.NET MVC 3 Preview 1 with Phil Haack/>
More Hanselminutes: Hanselminutes on 9 - ASP.NET MVC 3 and NEW ASP.NET Futures with Phil Haack and Morgan the Intern
Download ASP.NET MVC 3 Preview 1
Release notes

Brad Wilson has a four-part post on ASP.NET MVC 3’s new dependency injection support:

Creating Visual Studio projects that only contain static files

Eilon — Thu, 27 May 2010 20:00:00 GMT

Have you ever wanted to create a Visual Studio project that only contained static files and didn’t contain any code?

While working on ASP.NET MVC we had a need for exactly this type of project. Most of the projects in the ASP.NET MVC solution contain code, such as managed code (C#), unit test libraries (C#), and Script# code for generating our JavaScript code.

However, one of the projects, MvcFuturesFiles, contains no code at all. It only contains static files that get copied to the build output folder:

As you may well know, adding static files to an existing Visual Studio project is easy. Just add the file to the project and in the property grid set its Build Action to “Content” and the Copy to Output Directory to “Copy if newer.” This works great if you have just a few static files that go along with other code that gets compiled into an executable (EXE, DLL, etc.).

But this solution does not work well if the projects only contains static files and has no compiled code. If you create a new project in Visual Studio and add static files to it you’ll still get an EXE or DLL copied to the output folder, despite not having any actual code. We wanted to avoid having a teeny little DLL generated in the output folder.

In ASP.NET MVC 2 we came up with a simple solution to this problem. We started out with a regular C# Class Library project but then edited the project file to alter how it gets built. The critical part to get this to work is to define the MSBuild targets for Build, Clean, and Rebuild to perform custom tasks instead of running the compiler. The Build, Clean, and Rebuild targets are the three main targets that Visual Studio requires in every project so that the normal UI functions properly. If they are not defined then running certain commands in Visual Studio’s Build menu will cause errors.

Once you create the class library projects there are a few easy steps to change it into a static file project:

The first step in editing the csproj file is to remove the reference to the Microsoft.CSharp.targets file because the project doesn’t contain any C# code:

    <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />

The second step is to define the new Build, Clean, and Rebuild targets to delete and then copy the content files:

    <Target Name="Build">
        <Copy
            SourceFiles="@(Content)"
            DestinationFiles="@(Content->'$(OutputPath)%(RelativeDir)%(Filename)%(Extension)')" />
    </Target>
    <Target Name="Clean">
        <Exec Command="rd /s /q $(OutputPath)" Condition="Exists($(OutputPath))" />
    </Target>
    <Target Name="Rebuild" DependsOnTargets="Clean;Build">
    </Target>

The third and last step is to add all the files to the project as normal Content files (as you would do in any project type).

To see how we did this in the ASP.NET MVC 2 project you can download the source code and inspect the MvcFutureFules.csproj project file.

If you’re working on a project that contains many static files I hope this solution helps you out!

Last GUID used up - new ScottGuID unique ID to replace it

Eilon — Thu, 01 Apr 2010 12:00:00 GMT

You might have heard in recent news that the last ever GUID was used up. The GUID {FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF} was just consumed by a soon to be released project at Microsoft. Immediately after the GUID's creation the word spread around the Microsoft campuses around the globe. Microsoft's approximately 100,000 worldwide employees then started blogging, tweeting, and facebooking about the dubious "achievement." The following screenshot shows GUIDGEN (the Windows tool for creating GUIDs) with the last ever GUID.

All GUIDs created by projects at Microsoft must be registered in a central repository for record keeping. This allows quick-fix engineers, security engineers, anti-malware developers, and testers to do a quick look up of an unknown GUID and find out if it belongs to Microsoft. The following screenshot shows the Microsoft GUID Tracker internal application and the last few GUIDs being used up by various Microsoft projects.

What is perhaps more interesting than the news about the GUID is the project that used that last GUID. The recent announcements regarding the development experience for the Windows Phone 7 Series (WP7S) all involve free editions of Visual Studio 2010. One of the lesser known developer tools is based on a resurrected project that many of you are probably familiar with, but have never used. The tool is in fact Microsoft Bob 7 Series (MB7S). MB7S is an agent-based approach for mobile phone app development. The UI incorporates both natural language interfaces and motion gesture behaviors, similar to the Windows Phone 7 Series “Metro” interface. If it works, it will help to expand the breadth of mobile app developers.

After the GUID: The ScottGuID

It came as no big surprise that eventually the last GUID would be used up. Knowing this, a group of engineers at Microsoft has designed, implemented, and tested a replacement to the GUID: The ScottGuID. There are several core principles of the ScottGuID:

1. The concepts used in ScottGuIDs must be easily understood by a developer who is already familiar with GUIDs

2. There must exist a compatibility layer between ScottGuIDs and GUIDs

3. A ScottGuID must be usable in a practical manner in non-computing environments

4. There must exist ScottGuID APIs for all common platforms: Win32/Win64/WinCE, .NET (incl. Silverlight), Linux, FreeBSD, MacOS (incl. iPhone OS), Symbian, RIM BlackBerry, Google Android, etc.

5. ScottGuIDs must never run out

ScottGuID use cases

One of the more subtle principles of the ScottGuID is principle #3. While technically a GUID could be used in any environment, it was not practical to do so in terms of data entry and error detection. In order to have the ScottGuID be a true universal ID it must be usable in non-computing environments.

Prior to the announcement of the ScottGuID there have been a number of until-now confidential projects. One of the tools that will soon become public is ScottGuIDGen, which is in essence an updated version of GUIDGEN that can create ScottGuIDs. The following screenshot shows a sample ScottGuID.

To demonstrate the various applications of the ScottGuID there were test deployments around the globe. The following examples are a small showcase of the applications that have already been prototyped.

Log in to Hotmail:

Pay for gas:

Sign in to Twitter:

Dispense cat food:

Conclusion

I hope that this brief introduction to the ScottGuID shows how technology can continue to move forward, even when it appears there is a point that cannot be passed. With a small number of principles, a team of smart engineers, and a passion for "getting it right" the ScottGuID should last well past our lifetimes. In the coming months expect further announcements regarding additional developer tools, samples, whitepapers, podcasts, and videos.

Please leave a comment on this post if you have any questions about the ScottGuID or what you would like to see us do with it. With ScottGuID, the possibilities are nearly endless and we want to stretch their reach as far as possible.

Migrating ASP.NET MVC 1.0 applications to ASP.NET MVC 2 RTM

Eilon — Thu, 11 Mar 2010 06:00:00 GMT

ASP.NET MVC 2 RTM has just been released! More info on ScottGu's blog.

I have updated the MVC App Converter to convert projects from ASP.NET MVC 1.0 to ASP.NET MVC 2 RTM.

This should be last the last major change to the MVC App Converter that I released previews of in the past several months.

Download

The app is a single executable: Download MvcAppConverter-MVC2RTM.zip (255 KB).

Usage

The only requirement for this tool is that you have .NET Framework 3.5 SP1 on the machine. You do not need to have Visual Studio or ASP.NET MVC installed (unless you want to open your project!). Even though the tool performs an automatic backup of your solution it is recommended that you perform a manual backup of your solution as well.

To convert an ASP.NET MVC 1.0 project built with Visual Studio 2008 to an ASP.NET MVC 2 project in Visual Studio 2008 perform these steps:
- Launch the converter
- Select the solution
- Click the “Convert” button
To convert an ASP.NET MVC 1.0 project built with Visual Studio 2008 to an ASP.NET MVC 2 project in Visual Studio 2010:
- Wait until Visual Studio 2010 is released (next month!) and it will have a built-in version of this tool that will run automatically when you open an ASP.NET MVC 1.0 project
- Perform the above steps, then open the project in Visual Studio 2010 and it will perform the remaining conversion steps

What it can do

Open up ASP.NET MVC 1.0 projects from Visual Studio 2008 (no other versions of ASP.NET MVC or Visual Studio are supported)
Create a full backup of your solution’s folder
For every VB or C# project that has a reference to System.Web.Mvc.dll it will (this includes ASP.NET MVC web application projects as well as ASP.NET MVC test projects):
- Update references to ASP.NET MVC 2
- Add a reference to System.ComponentModel.DataAnnotations 3.5 (if not already present)
For every VB or C# ASP.NET MVC Web Application it will:
- Change the project type to an ASP.NET MVC 2 project
- Update the root ~/web.config references to ASP.NET MVC 2
- Update the root ~/web.config to have a binding redirect from ASP.NET MVC 1.0 to ASP.NET MVC 2
- Update the ~/Views/web.config references to ASP.NET MVC 2
- Add or update the JavaScript files (add jQuery, add jQuery.Validate, add Microsoft AJAX, add/update Microsoft MVC AJAX, add Microsoft MVC Validation adapter)
Unknown project types or project types that have nothing to do with ASP.NET MVC will not be updated

What it can’t do

It cannot convert projects directly to Visual Studio 2010 or to .NET Framework 4.
It can have issues if your solution contains projects that are not located under the solution directory.
If you are using a source control system it might have problems overwriting files. It is recommended that before converting you check out all files from the source control system.
It cannot change code in the application that might need to be changed due to breaking changes between ASP.NET MVC 1.0 and ASP.NET MVC 2.

Feedback, Please!

If you need to convert a project to ASP.NET MVC 2 please try out this application and hopefully you’re good to go. If you spot any bugs or features that don’t work leave a comment here and I will try to address these issues in an updated release.

Migrating ASP.NET MVC 1.0 applications to ASP.NET MVC 2 Beta (updated!)

Eilon — Mon, 23 Nov 2009 19:55:00 GMT

NOTE: There is an updated version of this tool that is compatible with ASP.NET MVC 2 RTM.

Thanks to the great feedback I’ve received on my ASP.NET MVC conversion tool for ASP.NET MVC 2 Preview 2 I’ve updated it to support conversions to ASP.NET MVC 2 Beta. I’ve included a number of bugs fixes and improvements based on the feedback:

The JavaScript files have been updated to be compatible with ASP.NET MVC 2 Beta
A “Scripts” folder will be automatically created if one does not already exist
References to the System.Web.Mvc.dll assembly will be updated to use the fully-qualified name (public key token, etc.)
UI improvements

Download

The app is a single executable: Download MvcAppConverter.zip (226 KB).

Usage

To convert an ASP.NET MVC 1.0 project built with Visual Studio 2008 to an ASP.NET MVC 2 project in Visual Studio 2008 perform these steps:
- Launch the converter
- Select the solution
- Click the “Convert” button
To convert an ASP.NET MVC 1.0 project built with Visual Studio 2008 to an ASP.NET MVC 2 project in Visual Studio 2010:
- Perform the above steps, then open the project in Visual Studio 2010 and it will perform the remaining conversion steps

What it can do

Open up ASP.NET MVC 1.0 projects from Visual Studio 2008 (no other versions of ASP.NET MVC or Visual Studio are supported)
Create a full backup of your solution’s folder
For every VB or C# project that has a reference to System.Web.Mvc.dll it will (this includes ASP.NET MVC web application projects as well as ASP.NET MVC test projects):
- Update references to ASP.NET MVC 2
- Add a reference to System.ComponentModel.DataAnnotations 3.5 (if not already present)
For every VB or C# ASP.NET MVC Web Application it will:
- Change the project type to an ASP.NET MVC 2 project
- Update the root ~/web.config references to ASP.NET MVC 2
- Update the root ~/web.config to have a binding redirect from ASP.NET MVC 1.0 to ASP.NET MVC 2
- Update the ~/Views/web.config references to ASP.NET MVC 2
- Add or update the JavaScript files (add jQuery, add jQuery.Validate, add Microsoft AJAX, add/update Microsoft MVC AJAX, add Microsoft MVC Validation adapter)
Unknown project types or project types that have nothing to do with ASP.NET MVC will not be updated

What it can’t do

It cannot convert projects directly to Visual Studio 2010 or to .NET Framework 4.
It can have issues if your solution contains projects that are not located under the solution directory.
If you are using a source control system it might have problems overwriting files. It is recommended that before converting you check out all files from the source control system.
It cannot change code in the application that might need to be changed due to breaking changes between ASP.NET MVC 1.0 and ASP.NET MVC 2. Consult the readme for information on breaking changes.

Feedback, Please!

Migrating ASP.NET MVC 1.0 applications to ASP.NET MVC 2

Eilon — Mon, 19 Oct 2009 19:38:00 GMT

NOTE: There is an updated version of this tool that is compatible with ASP.NET MVC 2 RTM.

To help our customers adopt ASP.NET MVC 2 I built an application that helps upgrade Visual Studio 2008 solutions that use ASP.NET MVC 1.0 to use ASP.NET MVC 2 Preview 2. This application is inspired by Scott Hanselman’s blog post on updating ASP.NET MVC projects to work in Visual Studio 2010 Beta 1.

Download

The app is a single executable: Download MvcAppConverter.zip (220 KB).

Usage

To convert an ASP.NET MVC 1.0 project built with Visual Studio 2008 to an ASP.NET MVC 2 project in Visual Studio 2008 perform these steps:
- Launch the converter
- Select the solution
- Click the “Convert” button
To convert an ASP.NET MVC 1.0 project built with Visual Studio 2008 to an ASP.NET MVC 2 project in Visual Studio 2010:
- Perform the above steps, then open the project in Visual Studio 2010 and it will perform the remaining conversion steps

What it can do

Open up ASP.NET MVC 1.0 projects from Visual Studio 2008 (no other versions of ASP.NET MVC or Visual Studio are supported)
Create a full backup of your solution’s folder
For every VB or C# project that has a reference to System.Web.Mvc.dll it will (this includes ASP.NET MVC web application projects as well as ASP.NET MVC test projects):
- Update references to ASP.NET MVC 2
- Add a reference to System.ComponentModel.DataAnnotations 3.5 (if not already present)
For every VB or C# ASP.NET MVC Web Application it will:
- Change the project type to an ASP.NET MVC 2 project
- Update the root ~/web.config references to ASP.NET MVC 2
- Update the root ~/web.config to have a binding redirect from ASP.NET MVC 1.0 to ASP.NET MVC 2
- Update the ~/Views/web.config references to ASP.NET MVC 2
- Add or update the JavaScript files (add jQuery, add jQuery.Validate, add Microsoft AJAX, add/update Microsoft MVC AJAX, add Microsoft MVC Validation adapter)
Unknown project types or project types that have nothing to do with ASP.NET MVC will not be updated

What it can’t do

It cannot convert projects directly to Visual Studio 2010 or to .NET Framework 4.
It can have issues if your solution contains projects that are not located under the solution directory.
If you are using a source control system it might have problems overwriting files. It is recommended that before converting you check out all files from the source control system.
It cannot change code in the application that might need to be changed due to breaking changes between ASP.NET MVC 1.0 and ASP.NET MVC 2. Consult the readme for information on breaking changes.

Feedback, Please!

Introducing SmartyRoute: A smarty-ier way to do routing in ASP.NET applications

Eilon — Wed, 07 Oct 2009 17:38:19 GMT

Inspired by ideas I have heard from people on my team (ideas that apparently I misunderstood!), I am introducing the new SmartyRoute, which provides a smarty-ier way to do routing in ASP.NET applications.

The basic idea is that you can make a request to a resource in an ASP.NET application without specifying a file extension in the URL. SmartyRoute will try to append a set of supported file extensions to find a handler to serve the request.

Basic Routing

In the simplest usage a user can make a request to ~/helloworld and SmartyRoute will find ~/helloworld.aspx on disk and use that as the handler. This is a very common scenario: Many developers don’t want to have file extensions in the URLs of their web sites. SmartyRoute enables developers to do that without making other changes to the application.

Slightly More Advanced Routing

A more advanced scenario is where a developer wants to have a URL such as ~/category/beverages. With the feature shown so far the developer has to have a ~/category/beverages.aspx on disk. There would also need to be another ASPX for every category in the application. However, SmartyRoute can walk up the path segments of the URL to locate a parent ASPX file. In this case SmartyRoute will detect that there is a file ~/category.aspx and load that instead. The rest of the data on the URL (in this case "beverages") can get passed in as parameters to the ASPX page.

Even More Advanced Routing

To get parameter values there are a number of helper APIs that SmartyRoute offers. The simplest way is to call SmartyRoute.GetRouteMatch().PathInfo, which will return everything after the last "/" of what was handled in the request. For example, if the user requests ~/category/beverages and it gets handled by ~/category.aspx then the remaining "beverages" value in the URL will be the path info:

    string category = SmartyRoute.GetRouteMatch().PathInfo; // category == "beverages"

If the path info contains multiple segments there is an alternative API that will do some of the heavier lifting for the developer. For example, if the URL is ~/category/beverages/5 (where "5" is the page number) there are these helpers:

    string category = SmartyRoute.GetNextRouteValue(); // category == "beverages"
    int page = SmartyRoute.GetNextRouteValue<int>(); // page == 5

Setting It Up

To use SmartyRoute in an application add a reference to the eStuff.Routing project and then go to your global.asax.cs and add this simple registration:

    string[] supportedExtensions = new[] { "aspx", "ashx" };
    RouteTable.Routes.Add(new SmartyRoute(supportedExtensions));

And that’s it!

Sample Project

In the attached sample project (13KB) there is the eStuff.Routing project and a sample ASP.NET Web Application Project. Open the solution in Visual Studio 2008 (with SP1) and try out these URLs:

http://localhost:59519/Default (will load ~/default.aspx)
http://localhost:59519/foo/bar (will load ~/foo/bar.aspx)
http://localhost:59519/category/beverages/5/soda (will load ~/category.aspx with parameters)
http://localhost:59519/MyHandlers/Boring (will load ~/MyHandlers/Boring.ashx handler)
http://localhost:59519/MyHandlers/CoolStuff/Quote (will try to load ~/MyHandlers/CoolStuff/Quote.ashx handler but will fail due to web.config security)

Note that you can still make requests using the file extensions: SmartyRoute doesn’t block any current functionality (not really, anyway).

Feedback, Please!

I’d love to hear whether people find this sort of routing functionality useful. The key advantage of this simplified routing system is that you, the developer, don’t have to specify any URL route formats, yet you get most of the advantages of ASP.NET Routing: Extensionless URLs, custom data in the path info, better SEO.

Would you use this in an application that you are building?

Are you already doing something similar in an existing application?

The String or the Cat: A New .NET Framework Library

Eilon — Wed, 01 Apr 2009 10:00:00 GMT

For years applications have been built that accept user input. Most user input starts out as a string. Strings are a universal representation of arbitrary data coming into a computer. However, most data does not remain as a string for very long. User input often ends up getting parsed or converted into another data type, such as an integer, Boolean value, or a date.

The concepts presented here are based on a thought experiment proposed by scientist Erwin Schrödinger. While an understanding of quantum physics will help to understand the new types and APIs, it is not required.

Mutation of data types leaves a software developer in an interesting situation if the data was not formatted properly and thus could not be mutated. For example, the string “abc123” cannot be parsed into an integer. Many frameworks deal with this situation by immediately reporting an error condition. That error could be an exception that was thrown or a Boolean value of false to indicate failure. Keeping track of these states can easily introduce uncertainty into an application.

StringOr<TOther>

The first class being introduced is the StringOr class. It is a generic class that encapsulates both the original string user input as well as the result of an attempted conversion operation.

namespace System.QuantumEntanglement {
    public class StringOr<TOther> {
        public StringOr(string stringValue, TOther otherValue);

        public string StringValue { get; }
        public TOther OtherValue { get; }
    }
}

The usage of the StringOr class is quite simple. An API that wishes to return data that might not have been parsed successfully can use the StringOr class to represent the dual state of its return value.

For example, a typical application might have a TextBox for entering an integer quantity:

If the consumer of this API wants the original value, they can use the StringValue property. Otherwise they can use the OtherValue property, which in this case is the successfully parsed integer.

The following diagram illustrates the dichotomy with a scenario familiar to many physicists:

SchrodingOr<TDead, TAlive>

The second class being introduced is the SchrodingOr class. It is similar to the StringOr, but with a distinct difference regarding its states. The SchrodingOr can represent any two data types: It is not restricted to one of the types being a string.

namespace System.QuantumEntanglement {
    public class SchrodingOr<TDead, TAlive> {
        public SchrodingOr(TDead dead, TAlive alive);

        public TAlive Alive { get; }
        public TDead Dead { get; }
    }
}

The usage of the SchrodingOr class is also similar to the StringOr. An API that wishes to return data that might be either of two data types, but never both data types at the same time, can return a SchrodingOr. The following code sample demonstrates a case where an API returns a value that can be either a bool or a DateTime.

Depending on the effects of quantum mechanics one of the two properties will return its value, while the other will throw a HeisenburgException. As before, the following diagram illustrates the dichotomy of the two possible values:

System.QuantumEntanglement Community Technology Preview

While the new .NET Framework library is still in relatively early stages of development, the team has decided to release a sneak preview to get feedback from our users. The link below contains the full source code for the new library, as well as unit tests that demonstrate proper usage of the libraries.

Class library with unit tests (requires Visual Studio 2008 Professional and higher)

Please send all questions, comments, and suggestions to string.or@microsoft.com.

Many thanks,

The .NET Framework Quantum Mechanics Team

ASP.NET MVC Release Candidate 2: I declare myself to be declarative!

Eilon — Wed, 04 Mar 2009 00:15:00 GMT

Today is a happy day: we released ASP.NET MVC Release Candidate 2. We're getting ever-so-close to the final (RTM/RTW) release of ASP.NET MVC - it won't be long! We think we fixed all the highest priority issues so that everyone out there can build ASP.NET MVC applications without worrying that we're going to make some sudden changes that will break you. Please see Phil's blog post announcing the release.

In this blog post I'll introduce you to a feature that's not even part of the main ASP.NET MVC download. It's part of the separate MVC Futures download, which includes prototypes of features that we're thinking of including in a future version of ASP.NET MVC.

Introduction to the MVC Controls

Before we dig into the details, let's create a simple ASP.NET MVC application that uses the MVC Controls.

1. Download the MVC Futures binary from CodePlex.

2. Create a new MVC Web Application Project (if asked, feel free to not create a unit test project). Please note that you must have Release Candidate 2 installed. Each release of ASP.NET MVC has a matching release of MVC Futures. Mixing releases is not supported and usually doesn't work.

3. Add a reference to the MVC Futures binary. Right-click on the References node in Solution Explorer and choose "Add Reference". Select the "Browse" tab and navigate to the location to which you saved Microsoft.Web.Mvc.dll, select the file, and select OK.

4. Edit the web.config in the root of the application to include tag mappings to the MVC Futures namespace. This tells the ASP.NET parser where to locate the controls when you type in an <mvc:SomeControl> tag. There should already be some tag mappings listed - the only new tag mapping is the third one with "mvc" as the tag prefix.

<pages>
  <controls>
    <add tagPrefix="asp" namespace="System.Web.UI" assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
    <add tagPrefix="asp" namespace="System.Web.UI.WebControls" assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
    <add tagPrefix="mvc" namespace="Microsoft.Web.Mvc.Controls" assembly="Microsoft.Web.Mvc"/>
  </controls>
  ...

5. Start using the controls!

Let's start out with a simple scenario of updating some of the Account and Membership features of the default template to use the MVC Controls.

1. Open up the ~/Views/Account/LogOn.aspx view page. The markup there should include this text box:

<%= Html.TextBox("username") %>

2. Change the text box markup to use the MVC TextBox control:

<mvc:TextBox runat="server" Name="username" />

(Please note that it sometimes takes Visual Studio a few moments to recognize new tag mappings. If Intellisense doesn't show up, please just give it a minute.)

3. Run the application and click "Log On" at the top-right of the page.

4. If all is well, the page should continue to have the exact same behavior as before. For example, if you immediately click "Log On" without typing in a username or password you should see the red highlight on the text box indicating an error.

The idea of the MVC Controls is that they are largely modeled after the HtmlHelpers, and thus try to preserve all their behavior. This includes naming conventions, the markup they render, and usage of model state.

Advanced MVC Controls

For a more advanced scenario involving the MVC Controls I'd like to introduce the MVC Repeater control. In many ways it is very similar to the ASP.NET Repeater control, but the main difference is of course that the MVC Repeater has specific knowledge of ViewData.

1. In the application you already created, open ~/Controllers/HomeController.cs (Sorry, I don't have a VB sample!) and add this new action method and two classes:

public ActionResult ProductList() {
    List<Distributor> distributors = new List<Distributor> {
        new Distributor { DistributorID = 501, Name = "Joe's Shop", Location = "Redmond, WA" },
        new Distributor { DistributorID = 502, Name = "Jill's Shop", Location = "Los Angeles, CA" },
        new Distributor { DistributorID = 503, Name = "Jeremy's Shop", Location = "Boston, MA" },
    };

    List<Product> products = new List<Product> {
        new Product {
            ProductID = 1001, 
            Name = "LEGO Technic Off Roader", 
            UnitPrice = 119.99m,
            Distributors = new List<Distributor> { distributors[0], distributors[1] } },
        new Product { 
            ProductID = 1002, 
            Name = "Ferrari F430", 
            UnitPrice = 189000m, 
            Distributors = new List<Distributor> { distributors[0], distributors[1], distributors[2] } },
        new Product { 
            ProductID = 1003, 
            Name = "Five bedroom house in Bellevue, WA",
            UnitPrice = 540000m, 
            Distributors = new List<Distributor> { } },
        new Product { 
            ProductID = 1004, 
            Name = "Dell 2007FP LCD monitor", 
            UnitPrice = 439m,
            Distributors = new List<Distributor> { distributors[2] } },
    };

    ViewData["products"] = products;

    return View();
}

public class Product {
    public int ProductID { get; set; }
    public string Name { get; set; }
    public decimal UnitPrice { get; set; }
    public IEnumerable<Distributor> Distributors { get; set; }
}

public class Distributor {
    public int DistributorID { get; set; }
    public string Name { get; set; }
    public string Location { get; set; }
}

2. Right-click anywhere in the action method and choose Add View with the default options and select "Add":

3. In the newly created view add this ASPX markup to the second content placeholder (right below the <h2> tag):

<mvc:Repeater runat="server" Name="products">
    <ItemTemplate>
        <b><mvc:Label runat="server" Name="Name" /></b>
        (PID#<mvc:Label runat="server" Name="ProductID" />)
        $<mvc:Label runat="server" Name="UnitPrice" /><br />
        Distributors:<br />
        <mvc:Repeater runat="server" Name="distributors">
            <ItemTemplate>
                - <b><mvc:Label runat="server" Name="Name" /></b>
                (DID#<mvc:Label runat="server" Name="DistributorID" />),
                located in <mvc:Label runat="server" Name="Location" /><br />
            </ItemTemplate>
            <EmptyDataTemplate>
                - Sorry, there are no distributors for this item<br />
            </EmptyDataTemplate>
        </mvc:Repeater>
        <br />
    </ItemTemplate>
</mvc:Repeater>

Please note that when you paste in the code Visual Studio might add an "ID" attribute to every control tag. You can delete all those attributes if you don't want them - but it's fine to leave them.

4. Run the page and you will get this nested databound rendering:

Advantages of MVC Controls Over Code Nuggets

If you've used the default WebFormViewEngine in ASP.NET MVC, you've certainly used this syntax somewhere in your views:

<%= Html.TextBox("FirstName") %>

What you might not know is that this syntax is called a "code nugget." While there is nothing inherently wrong with using code nuggets, one advantage of using MVC Controls is that they can provide a rich design-time experience. Many developers, even those who are familiar with the intricacies of HTML and CSS, like to get an accurate preview of what their page will look like without running the application.

If you've used ASP.NET Web Forms and controls such as the SqlDataSource and the GridView, you've seen how rich a design-time experience can be. Those controls include design time rendering previews, advanced template editing, and even wizards that walk you through the steps of configuring the controls.

The MVC Controls in the MVC Futures download are just a start: they certainly don't have the fit and finish that is seen in the SqlDataSource design-time experience. Like many rumors about ASP.NET MVC itself have stated, the beginnings of the MVC Controls were in fact written on an airplane!

Compare the areas in the following screen shot of the text box we created earlier to see the difference. The MVC Control has a proper preview, whereas the HTML Helper doesn't render at all.

Disadvantages of MVC Controls

One of the biggest disadvantages of the MVC Controls is that there is a rather immediate limit to how you can use them. For example, take this relatively simple scenario with the regular TextBox HtmlHelper:

<%= Html.TextBox("FirstName", Model.FirstName.ToUpper()) %>

There is no simple way to do this with the MVC Controls because there is no place to add your own code to pre-process the values.

Another disadvantage is that the MVC Controls work only with the WebFormViewEngine. There are several other view engines out there that people have been using with ASP.NET MVC. Some of the popular third party view engines out there are Spark view engine, NHaml, and the view engines included in the MVC Contrib project, which are Brail, NVelocity, and XSLT.

For ASP.NET MVC 1.0 we decided on the MVC team to focus our efforts on features that have the widest possible benefit. In this case it meant writing helpers that worked with as many different view engines as possible.

As a slight bit of humor (though it's in fact serious), please refer to Eric Lippert's blog post How many Microsoft employees does it take to change a lightbulb?

The Future of the MVC Controls

As I mentioned in the top of the post, the MVC Controls are just a prototype. They are not complete; they are not set in stone; and there is no guarantee that they will ever be part of the main ASP.NET MVC download.

I already have a long list of improvements to make to the MVC Controls. I plan to add many more controls as well as more advanced features to existing controls.

If you have any feedback, comments, or suggestions on the MVC Controls feel free to post them here. We take all feedback seriously!

Some questions to think about:

Do you see yourself using the MVC Controls?
- If so, why?
- If not, why not?
What MVC Controls would you see yourself using the most? (Even ones that don't exist yet.)

Opening an ASP.NET MVC project without having ASP.NET MVC installed: The project type is not supported by this installation

Eilon — Tue, 20 Jan 2009 13:00:24 GMT

Projects built with ASP.NET MVC are what are known as "flavored projects." This means that instead of being an entirely new project type, ASP.NET MVC projects merely extend a different kind of existing project type. Specifically, the projects extend the Web Application Project type.

If you try to open a flavored project and don't have that particular flavored project system installed, you get to see this little slice of heaven:

If you select "OK" then Visual Studio will continue, but the project will not be loaded:

Well, then, what do you do to continue? All you have to do is edit the project file to remove the flavoring. Right-click on the project, and select "Edit MyProjectName.vbproj".

This will launch Visual Studio's project file editor (with Intellisense, in case you didn't know!). Towards the top you'll see a list of project types associated with this project, each one represented by a GUID.

  <ProjectTypeGuids>{603c0e0b-db56-11dc-be95-000d561079b0};{349c5851-65df-11da-9384-00065b846f21};{F184B08F-C81C-45F6-A57F-5ABD9991F28F}</ProjectTypeGuids>

The first GUID there (the one that starts with "603c") is the one used by ASP.NET MVC projects. Remove that GUID so you end up with:

  <ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{F184B08F-C81C-45F6-A57F-5ABD9991F28F}</ProjectTypeGuids>

Save the project file and close it.

Now reload the project:

And you'll be able to work on the project once again. The only thing you won't be able to use is MVC project-specific features such as the "Add View" menu option.

I find myself doing this very often since my work machine is always in a bizarre state with respect to ASP.NET MVC and I often don't have the project type installed. This is much faster than trying to install MVC just so I can inspect a project.

Optimizing your route collection for URL generation in ASP.NET MVC (and more!)

Eilon — Thu, 18 Dec 2008 05:00:49 GMT

If you're used ASP.NET MVC or ASP.NET Dynamic Data, you've using ASP.NET's new Routing feature. ASP.NET Routing is the feature that lets you easily create so-called "pretty" URLs. Pretty URLs are the ones that look the way you want them to look (e.g. ~/products/beverages), not the way your web application platform forces them to look (e.g. ~/products.aspx?categoryname=beverages).

Many people, including myself, have blogged about the various features of Routing, but this post is about optimizing your routes to get the most out of them.

Here are some tricks to make URL generation more performant in your application:

1. Use named routes

Named routes are an optional feature of routing. The names are only used for URL generation; they are never used for matching incoming URLs. When you specify a name when generating a URL we will only try to match the one route with that name. This means that even if the named route you specified is the 100th route in the route table we'll jump straight to it and try to match. Otherwise we'd try every single route until we get to the 100th route. Here's an example of using named routes in an MVC application:

// Global.asax.cs

routes.MapRoute(
    "products-route",
    "products/{category}",
    new {
        controller = "products",
        action = "category",
    });

// Views/Home/Index.aspx

<%= Html.RouteLink("Show Beverages", "products-route", new { category = "beverages" }) %>

Note that if we hadn't specified the name route, we would probably get a different route to match. Also, because we used the named route, we didn't have to specify any extra route values such as the controller or action name.

2. Put your most common routes at the beginning of the route table

This will improve performance of both URL generation as well as processing incoming URLs. The Routing system works on a very simple rule: the first match wins. If the first match happens to be the 100th route in your route table, then that means it had to try 99 other routes and none of them matched. By putting your most common routes towards the top of the route collection, they will match sooner.

However, be careful: Changing the order of your routes can affect how they match. Only change the order of the routes if you're sure that it won't cause a conflict.

3. Don't use URL generation

Some people like URL generation and some people don't. It's a bit tricky to master URL generation. It's nice to use URL generation if your URLs are very dynamic and you don't want to update your whole site when you make changes to your URL structure. But it can be a bit of a hassle when you have very few URLs to begin with and perhaps you don't care about exactly what they look like.

My favorite

My favorite option is #1, using named routes, primarily since it's super easy to use. It also makes URL generation more deterministic from the app developer's perspective (that's you!). By giving things names and then specifying exactly what you won't, it eliminates the guessing game of routes.

Upcoming talks: Microsoft Tech Ed South Africa

Eilon — Wed, 23 Jul 2008 05:55:02 GMT

In just a couple of weeks I'll be in Durban, South Africa presenting three sessions at Tech Ed. These are the sessions:

WEB304: Introduction to MVC Web Development

Day: Monday, 04 August 2008, 09:15 - 10:30
Location: Session Room 07
One of the benefits of using a MVC methodology is that it helps enforce a clean separation of concerns between the models, views, and controllers within an application. In the very near future, ASP.NET will include support for developing Web applications using an MVC-based architecture. The MVC pattern can also help enable red/green test-driven development (TDD) where you implement automated unit tests, which define and verify the requirements of new code, before you actually write the code itself. Join us for a dive into the new MVC Framework and learn how to leverage this new alternative in your own applications.

WEB306: What's new in Visual Studio 2008 for ASP.NET developers

Day: Monday, 04 August 2008, 16:15 - 17:15
Location: Session Room 08
Check out the latest and greatest with Microsoft Visual Studio 2008. From the CSS designer to JavaScript Intellisense, Visual Studio 2008 packs a powerful punch for building rich web applications. You’ll also see how to use LINQ data access and unit testing in a web application.

WEB307: A Tour of What’s New in ASP.NET 3.5

Day: Tuesday, 05 August 2008, 16:45 - 17:45
Location: Session Room 07
Discover how you can take advantage of the latest enhancements to ASP.NET and Visual Studio 2008 for building Web applications in your real-world applications. Enhance your web application with AJAX, Silverlight, and LINQ data access. You’ll also see how to use ASP.NET Dynamic Data to build a data entry site in a matter of minutes.

* Dates, times, and locations can change, so check your schedules!

I hope to see some of you there, so please stop by and say hi!

HttpContext.IsCustomErrorEnabled - One of ASP.NET's hidden gems

Eilon — Mon, 14 Jul 2008 03:30:26 GMT

Calling a property a gem might be a bit of an exaggeration, but this particular property is still rather valuable. In many situations a developer wants to enable a feature or part of a feature only for debugging and testing purposes. The IsCustomErrorEnabled property combines three values to tell you whether custom errors are enabled for a particular request. This isn't as simple as reading the web.config file to check the <customErrors> section. There's a bit more going on behind the scenes to truly determine whether custom errors are enabled.

The property looks at these three values:

The web.config's <deployment> section's retail property. This is a useful property to set when deploying your application to a production server. This overrides any other settings for custom errors.
The web.config's <customErrors> section's mode property. This setting indicates whether custom errors are enabled at all, and if so whether they are enabled only for remote requests.
The HttpRequest object's IsLocal property. If custom errors are enabled only for remote requests, you need to know whether the request is from a remote computer.

The property is used in several places in ASP.NET to determine what type of error message to display to the user. When custom errors are enabled, the error messages tend to be terse so as not to disclose any secret information. When custom errors are disabled, more extensive information is displayed to the user including stack traces, type names, and file paths. One of the nice things about this property is that it works in all trust levels (well, at least Medium trust and higher - I'm not sure about Low and Minimal). It's also nice that you don't have to worry about reading from web.config manually.

Just recently in ASP.NET MVC we added a feature where we used this property to determine whether to show a generic error message such as "Your site is broken!" instead of full stack traces and debugging information. I hope this property ends up getting called by your ASP.NET applications and controls!

MVC: Unit testing controller actions that use TempData

Eilon — Mon, 14 Apr 2008 04:00:52 GMT

Part of the "big deal" about ASP.NET MVC, and of course MVC in general, is that the code you write is more easily unit tested as compared to traditional ASP.NET WebForms. However, if you've used ASP.NET MVC and tried to write a unit test for a controller action that uses TempData, you probably got some exceptions about null references and other crazy stuff. I've seen a number of solutions out there that involve private reflection (which is kind of evil) so I figured I'd show how it can be done without that trickery. (Kudos, though, to those of you who figured out how to do such trickery!)

The underlying problem is that the TempDataDictionary object tries to read from session state when it's first used. At unit test time ASP.NET is not running so there isn't any session state. The solution is to provide a mock session state object to the TempDataDictionary. We're basically telling TempDataDictionary, "Hey you want some session state??? Here's your session state!!!"

The controller we're going to test has two actions. The first action adds a value to TempData and then does a redirect. The second action checks for the existence of the value in TempData and renders a view.

public class HomeController : Controller {
    public void Index() {
        // Save UserID into TempData and redirect to greeting page
        TempData["UserID"] = "user123";
        RedirectToAction("GreetUser");
    }

    public void GreetUser() {
        // Check that the UserID is present. If it's not
        // there, redirect to error page. If it is, show
        // the greet user view.
        if (!TempData.ContainsKey("UserID")) {
            RedirectToAction("ErrorPage");
            return;
        }
        ViewData["NewUserID"] = TempData["UserID"];
        RenderView("GreetUser");
    }
}

In order to write the unit tests I created a mock HttpContext with a mock session state object:

// HttpContext for TempData that uses a custom
// session object.
public class TestTempDataHttpContext : HttpContextBase {
    private TestTempDataHttpSessionState _sessionState =
        new TestTempDataHttpSessionState();

    public override HttpSessionStateBase Session {
        get {
            return _sessionState;
        }
    }
}

// HttpSessionState for TempData that uses a custom
// session object.
public class TestTempDataHttpSessionState : HttpSessionStateBase {
    // This string is "borrowed" from the ASP.NET MVC source code
    private string TempDataSessionStateKey = "__ControllerTempData";
    private object _tempDataObject;

    public override object this[string name] {
        get {
            Assert.AreEqual<string>(
                TempDataSessionStateKey,
                name,
                "Wrong session key used");
            return _tempDataObject;
        }
        set {
            Assert.AreEqual<string>(
                TempDataSessionStateKey,
                name,
                "Wrong session key used");
            _tempDataObject = value;
        }
    }
}

Each unit test that involves an action that uses TempData needs to create a custom TestTempDataHttpContext object and use that in a new instance of TempDataDictionary:

TestTempDataHttpContext tempDataHttpContext = new TestTempDataHttpContext();
homeController.TempData = new TempDataDictionary(tempDataHttpContext);

I wrote three unit tests for HomeController:

Test that the Index action sets the right TempData and does a redirect
Test that the GreetUser action redirects when the TempData is missing the value
Test that the GreetUser action renders the GreetUser view with the right ViewData when the TempData has the right value

And here are the unit tests:

[TestClass]
public class HomeControllerTest {
    [TestMethod]
    public void IndexSavesUserIDToTempDataAndRedirects() {
        // Setup
        TestHomeController homeController = new TestHomeController();
        TestTempDataHttpContext tempDataHttpContext = new TestTempDataHttpContext();
        homeController.TempData = new TempDataDictionary(tempDataHttpContext);

        // Execute
        homeController.Index();

        // Verify
        Assert.IsTrue(homeController.RedirectValues.ContainsKey("action"));
        Assert.AreEqual("GreetUser", homeController.RedirectValues["action"]);

        Assert.IsTrue(homeController.TempData.ContainsKey("UserID"));
        Assert.AreEqual("user123", homeController.TempData["UserID"]);
    }

    [TestMethod]
    public void GreetUserWithNoUserIDRedirects() {
        // Setup
        TestHomeController homeController = new TestHomeController();
        TestTempDataHttpContext tempDataHttpContext = new TestTempDataHttpContext();
        homeController.TempData = new TempDataDictionary(tempDataHttpContext);

        // Execute
        homeController.GreetUser();

        // Verify
        Assert.IsTrue(homeController.RedirectValues.ContainsKey("action"));
        Assert.AreEqual("ErrorPage", homeController.RedirectValues["action"]);

        Assert.AreEqual(0, homeController.TempData.Count);
    }

    [TestMethod]
    public void GreetUserWithUserIDCopiesToViewDataAndRenders() {
        // Setup
        TestHomeController homeController = new TestHomeController();
        TestTempDataHttpContext tempDataHttpContext = new TestTempDataHttpContext();
        homeController.TempData = new TempDataDictionary(tempDataHttpContext);
        homeController.TempData["UserID"] = "TestUserID";

        // Execute
        homeController.GreetUser();

        // Verify
        Assert.AreEqual<string>("GreetUser", homeController.RenderViewName);
        Assert.AreEqual<string>(String.Empty, homeController.RenderMasterName);
        IDictionary<string, object> viewData =
            homeController.RenderViewData as IDictionary<string, object>;
        Assert.IsNotNull(viewData);
        Assert.IsTrue(viewData.ContainsKey("NewUserID"));
        Assert.AreEqual("TestUserID", viewData["NewUserID"]);
    }

    // Test-specific subclass for HomeController. This won't be
    // needed in the next release of ASP.NET MVC.
    private sealed class TestHomeController : HomeController {
        public RouteValueDictionary RedirectValues;
        public string RenderViewName;
        public string RenderMasterName;
        public object RenderViewData;

        protected override void RedirectToAction(RouteValueDictionary values) {
            RedirectValues = values;
        }

        protected override void RenderView(string viewName, string masterName,
            object viewData) {
            RenderViewName = viewName;
            RenderMasterName = masterName;
            RenderViewData = viewData;
        }
    }
}

Some notes about the code:

For the unit tests I also needed to create a test-specific subclass for HomeController called TestHomeController in order to capture the values of a call to RedirectToAction and RenderView. In the upcoming preview of ASP.NET MVC this class won't be needed due to some changes we've made.
Making TempData easier to unit test is on our list of improvements for a later preview of ASP.NET MVC. We realize it's a bit tricky right now, and we plan to make it much, much easier.
Instead of creating concrete classes for the custom HttpContext and session state objects you could use a mock object framework to dynamically generate those instances. I chose not to show that since it might detract from the purpose of the post. If you're already using a mock object framework such as RhinoMocks or Moq it should be easy to modify the code to use those frameworks.

I hope you find this sample useful when you're writing your unit tests. If you have any other pain points in ASP.NET MVC please post a comment so we'll know about it.

MVC: Locking the RouteCollection

Eilon — Mon, 31 Mar 2008 22:00:00 GMT

Since the advent of multithreaded programming, the responsibility of locking collections has always been a contentious issue. Who should lock the collection? When should it be locked? And for how long? The ASP.NET Routing feature that is used by the MVC framework involves a thread-safe collection that contains the list of the application's route definitions. Will your routes be safe? Continue reading to find out (on this amazing journey (into the depths of the RouteCollection)). How's that for a cheesy intro?

The problem

When the first preview of ASP.NET MVC was released last December, some people noted that the RouteCollection would lock itself during all read and write operations, which could cause major performance and scaling issues. Well, sort of. The RouteCollection class derives from the generic Collection<T>, which has a few virtual methods it calls when write operations are performed. Each of those methods was overridden in RouteCollection to take a full lock. The route operations of matching routes to incoming requests and generating URLs also took the same full lock. There were two problems (at least) with this approach:

Taking a full lock means that if anyone is using the collection, any other operation on that collection would have to wait for the first one to be done. Even if two requests just wanted to enumerate the collection (a read-only operation), one request would have to wait. This wasn't a logic bug since it wouldn't prevent anything from working; It was just a performance issue. There was in fact a comment in the code along the lines of "TODO: Shouldn't we use a ReaderWriterLockSlim here or something?"
We weren't locking enough! If someone directly enumerated the collection by calling GetEnumerator (which happens implicitly when you use C# or VB's foreach statement), no lock would be taken. Unfortunately, Collection<T> does not offer any virtual methods that get called during read operations.

The solution (or so we thought)

We knew we had to do something for ASP.NET MVC Preview 2: We had performance problems as well as bugs in our collection locking. The first thing we did was change the lock to be a multiple-reader, single-writer lock with the ReaderWriterLockSlim class. Using this class in the RouteCollection allows any number of readers to read the collection at the same time but will fully lock the collection when a write is performed and allow only that one writer to make changes until the write lock is released.

Before we knew it, though, a bug was found while running some performance tests. When there is contention for the lock, the ReaderWriterLockSlim needs to get the processor count of the server. For some reason or another, getting that count is not permitted in Medium Trust web applications and thus throws a SecurityException. We didn't notice this while we were writing unit tests and web tests because all those tests are single threaded: there is never any contention for the lock.

The final solution

We opened a work item for the owners of Environment.ProcessorCount to remove the security requirement since knowing the processor count of the host is hardly top secret information. However, since the ASP.NET Routing feature works on .NET Framework 3.5, bug fixes in a future version wouldn't be sufficient. Thus we changed RouteCollection to use ReaderWriterLock, which is slightly less performant, but works in all web trust levels.

So we solved the problem of when the collection gets locked and for how long. But what about the very first issue I mentioned: Who should lock the collection?

Our first solution was to do all the locking internally. Any time you called any member on the collection we'd take the appropriate lock. This meant implementing IList<T> directly since neither Collection<T> nor List<T> provide the necessary hooks. This proved to be a lot of work (but not for me, since I didn't have to write it ) and left some big holes of functionality. For example, how could someone atomically search for a route in the collection, remove it, and add a new route?

The solution to that problem was to expose the lock semantics publicly, though without exposing the lock object itself. Thus the RouteCollection has two new methods: GetReadLock and GetWriteLock. Developers can call those methods to get the lock that the RouteCollection uses internally and cooperate with its locking mechanism. However, you only need to get the lock if you're directly accessing the collection. If you're going through any of the typical "end-user" API calls, we do the locking automatically. For example, calling Html.ActionLink, Url.Action, and RouteCollection.GetVirtualPath will automatically lock the collection.

In case you're wondering, there were several reasons we chose not to expose the lock object itself:

We wanted to be able to change the lock implementation at any time. This would let us switch back to ReaderWriterLockSlim at some point in the future.
It seemed simpler for users to have a limited API surface. Less is More.
It encourages users to use the dispose pattern with the lock they get, thus ensuring that the lock is released even if an exception is thrown and not caught while the lock is being held.

Why you should care

There are two takeaways I hope I provided in this article:

The first takeaway is that if you're implementing a thread-safe collection you have some food for thought. I hope the food was easy to digest!

The second takeaway is that if you're directly accessing the RouteCollection in an ASP.NET application, make sure you take the lock first! Taking the lock is easy with the dispose pattern:

RouteCollection routes = RouteTable.Routes;
using (routes.GetReadLock()) {
    foreach (RouteBase route in routes) {
        // Do something interesting here and be guaranteed that no one is modifying the collection
    }
}
// The lock is now released since we exited the "using" statement.

Who would have thought that a simple collection of routes would turn out to be so much fun? Did you ever start coding something that seemed simple and ended up writing a long blog post about it?