nuget, open source, code comments edit

Hi there, it’s time to shine the bat-signal, or better yet, the NuGet-Signal!

batman-sending-nuget-signalThe NuGet community needs your help! We’re wrestling with some interesting wide ranging design decisions and we need data to test out our assumptions and help us make the best possible choices. I won’t go into too much detail about the specific issue as I don’t want to bias the results of the following survey. I simply want to gather information about common practices by answering a set of questions that mostly have empirical answers.

I think it’s a given that most Visual Studio solutions consist of multiple projects. What’s I’m not so sure about is how often those solutions consist of multiple applications?

For example, is it more common for your solution to have a single core app and all of the other projects support that app?


Or is it more common to have a solution with two different apps such as two WinForm apps or two web apps?


So please answer the following questions:

This survey requires using a browser that supports iframes.

As an example for that last question, here’s the packages folder for a sample solution I created. It has four packages where there are multiple versions.


Thanks for taking the time to answer these questions. I’ll follow up later with more details on what we’re working on.

And feel free to elaborate in the comments if you have more to say!

nuget,, code comments edit

As you may know, NuGet supports aggregating packages from multiple package sources. You can simply point NuGet at a folder containing packages or at a NuGet OData service.

A while back I wrote up a guide to hosting your own NuGet feed. Well, we’ve made it way easier to set one up now! And, surprise surprise, it involves NuGet. Smile I’ll provide step by step instructions here. But first, make sure you’re running NuGet 1.2!

Step 1: Create a new Empty Web Application in Visual Studio

Go to the File | New | Project menu option (or just hit CTRL + SHIFT + N) which will bring up the new project dialog and select “ASP.NET Empty Web Application” as in the following screenshot (click to enlarge).


This results in a very empty project template.


Step 2: Install the NuGet.Server Package

Now right click on the References node and select Add Library Package Reference to launch the NuGet dialog (alternatively, you can use the Package Manager Console instead and type Install-Package NuGet.Server).

Click the Online tab and then type NuGet.Server in the top right search box. Click Install on the NuGet.Server package as shown in the following image (click to enlarge).


Step 3: Add Packages to the Packages folder

That’s it! The NuGet.Server package just converted your empty website into a site that’s ready to serve up the OData package feed. Just add packages into the Packages folder and they’ll show up.

In the following screenshot, you can see that I’ve added a few packages to the Packages folder.


Step 4: Deploy and run your brand new Package Feed!

I can hit CTRL + F5 to run the site and it’ll provide some instructions on what to do next.


Clicking on “here” shows the OData over ATOM feed of packages.


Now all I need to do is deploy this website as I would any other site and then I can click the Settings button and add this feed to my set of package sources as in the following screenshot (click to enlarge).


Note that the URL you need to put in is http://yourdomain/nuget/ depending on how you deploy the site.

Yes, it’s that easy! Note that this feed is “read-only” in the sense that it doesn’t support publishing to it via the NuGet.exe command line tool. Instead, you need to add packages to the Packages folder and they are automatically syndicated.

nuget, code, open source comments edit

I’m happy to announce the release of NuGet 1.2. It took us a bit longer than we expected to get this release out there, and I’ll explain why later, but for now, go install it!

Upgrade!If you go into Visual Studio and select Tools | Extension Manager, click on the Update tab and you’ll see that this new version of NuGet should be available as an update. It only takes a minute and it really is that easy to upgrade.

For more details about what’s in this release, check out the announcement on

There’s also a new version of NuGet.exe corresponding with this release as well as the Package Explorer. If you have a fairly recent version of NuGet.exe, you can upgrade it by simply running the following command:

NuGet.exe u


Thanks to everyone who helped make this happen. I’ll be writing about our plans for 1.3 fairly soon. Smile

code comments edit

A colleague of mine from the Data and Modeling Group mentioned that they have a new senior developer position open working on their new datajs project.

This developer would be responsible for defining how modern web and mobile applications use and interact with data on JavaScript platforms. We deal with and work on defining a number of standards including HTML5’s IndexedDB and OData, as well as provide a new set of end-to-end experiences for accessing, managing, and storing data in JS.

What’s interesting to me is that datajs appears to be an open source project under the MIT license!

From its description on the datajs CodePlex page,

datajs is a new cross-browser JavaScript library that enables data-centric web applications by leveraging modern protocols such as JSON and OData and HTML5-enabled browser features. It’s designed to be small, fast and easy to use. \

For more details about the position, check out the job posting online.

For those of you who are interested but don’t live in Redmond, Washington, this position is in Redmond and requires relocation.

How do I apply?

If you’re interested in the position, please contact Jeff Derstadt I don’t know anything more about the job than what I posted here in this blog post.

I do know that I’ve worked with people on that team as partners on in various capacities and they’re smart folks doing good work. I’m sure my team and your team (should you get the job) would end up working closely together. Smile mvc,, code comments edit

I’m in the beautiful country of Brazil right now (I’ll hopefully blog more about that later) proctoring for the hands-on labs that’s part of the Web Camps agenda.

However, the folks here are keeping me on my toes asking me to give impromptu and deeply advanced demos. It almost feels like a form of performance art as I create brand new demos on the fly. Smile

During this time, several people reported issues binding to a decimal value that prompted me to write a new demo and this blog post.

Let’s look at the scenario. Suppose you have the following class (Jogadoris a soccer player in Portugese):

public class Jogador {
    public int ID { get; set; }
    public string Name { get; set; }
    public decimal Salary { get; set; }

And you have two controller actions, one that renders a form used to create a Jogador and another action method that receives the POST request.

public ActionResult Create() {
  // Code inside here is not important
  return View();

public ActionResult Create(Jogador player) {
  // Code inside here is not important
  return View();  

When you type in a value such as 1234567.55 into the Salary field and try to post it, it works fine. But typically, you would want to type it like 1,234,567.55 (or here in Brazil, you would type it as 1.234.567,55).

In that case, the DefaultModelBinder chokes on the value. This is unfortunate because jQuery Validate allows that value just fine. I’ll talk to the rest of my team about whether we should fix this in the next version of ASP.NET MVC, but for now it’s good to know there’s a workaround.

In general, we recommend folks don’t write custom model binders because they’re difficult to get right and they’re rarely needed. The issue I’m discussing in this post might be one of those cases where it’s warranted.

Here’s the code for my DecimalModelBinder. I should probably write one for other decimal types too, but I’m lazy.

WARNING: This is sample code! I haven’t tried to optimize it or test all scenarios. I know it works for direct decimal arguments to action methods as well as decimal properties when binding to complex objects.

using System;
using System.Globalization;
using System.Web.Mvc;

public class DecimalModelBinder : IModelBinder {
    public object BindModel(ControllerContext controllerContext, 
        ModelBindingContext bindingContext) {
        ValueProviderResult valueResult = bindingContext.ValueProvider
        ModelState modelState = new ModelState { Value = valueResult };
        object actualValue = null;
        try {
            actualValue = Convert.ToDecimal(valueResult.AttemptedValue, 
        catch (FormatException e) {

        bindingContext.ModelState.Add(bindingContext.ModelName, modelState);
        return actualValue;

With this in place, you can easily register this in Application_Start within Global.asax.cs.

protected void Application_Start() {
    ModelBinders.Binders.Add(typeof(decimal), new DecimalModelBinder());

    // All that other stuff you usually put in here...

That registers our model binder to only be applied to decimal types, which is good since we wouldn’t want model binding to try and use this model binder when binding any other type.

With this in place, the Salary field will now accept both 1234567.55and 1,234,567.55.

Hope you find this useful. I’ve had a great time in Buenos Aires, Argentina and São Paulo, Brazil. I’ll probably be swamped when I get back home, but I’ll try to make time to write about my time here., mvc comments edit

Layouts in Razor serve the same purpose as Master Pages do in Web Forms. They allow you to specify a layout for your site and carve out some placeholder sections for your views to implement.

For example, here’s a simple layout with a main body section and a footer section.

<!DOCTYPE html>
<head><title>Sample Layout</head>

In order to use this layout, your view might look like.

    Layout = "MyLayout.cshtml";
<h1>Main Content!</h1>
@section Footer {
    This is the footer.

Notice we use the @section syntax to specify the contents for the defined Footer section.

But what if we have other views that don’t specify content for the Footer section? They’ll throw an exception stating that the “Footer” section wasn’t defined.

To make a section optional, we need to call an overload of RenderSection and specify false for the required parameter.

<!DOCTYPE html>
<head><title>Sample Layout</head>
    <footer>@RenderSection("Footer", false)</footer>

But wouldn’t it be nicer if we could define some default content in the case that the section isn’t defined in the view?

Well here’s one way. It’s a bit ugly, but it works.

  @if (IsSectionDefined("Footer")) {
  else { 
      <span>This is the default yo!</span>   

That’s some ugly code. If only there were a way to write a version of RenderSection that could accept some Razor markup as a parameter to the method.

Templated Razor Delegates to the rescue! See, I told you these things would come in handy.

We can write an extension method on WebPageBase that encapsulates this bit of ugly boilerplate code. Here’s the implementation.

public static class Helpers {
  public static HelperResult RenderSection(this WebPageBase webPage, 
      string name, Func<dynamic, HelperResult> defaultContents) {
    if (webPage.IsSectionDefined(name)) {
      return webPage.RenderSection(name);
    return defaultContents(null);

What’s more interesting than this code is how we can use it now. My Layout now can do the following to define the Footer section:

  @this.RenderSection("Footer", @<span>This is the default!</span>)

That’s much cleaner! But we can do even better. Notice how there’s that ugly this keyword? That’s necessary because when you write an extension method on the current class, you have to call it using the this kewyord.

Remember when I wrote about how to change the base type of a Razor view? Here’s a case where that really comes in handy.

What we can do is write our own custom base page type (such as the CustomWebViewPage class I used in that blog post) and add the RenderSection method above as an instance method on that class. I’ll leave this as an exercise for the reader.

The end result will let you do the following:

  @RenderSection("Footer", @<span>This is the default!</span>)

Pretty slick!

You might be wondering why we didn’t just include this feature in Razor. My guess is that we wanted to but just ran out of time. Hopefully this will make it in the next version of Razor. mvc, code, razor comments edit

David Fowler turned me on to a really cool feature of Razor I hadn’t realized made it into 1.0, Templated Razor Delegates. What’s that? I’ll let the code do the speaking.

  Func<dynamic, object> b = @<strong>@item</strong>;
<span>This sentence is @b("In Bold").</span>

That could come in handy if you have friends who’ll jump on your case for using the bold tag instead of the strong tag because it’s “not semantic”. Yeah, I’m looking at you Damian :stuck_out_tongue:  I mean, don’t both words signify being forceful? I digress.

Note that the delegate that’s generated is a Func<T, HelperResult>. Also, the @item parameter is a special magic parameter. These delegates are only allowed one such parameter, but the template can call into that parameter as many times as it needs.

The example I showed is pretty trivial. I know what you’re thinking. Why not use a helper? Show me an example where this is really useful. Ok, you got it!

Suppose I wrote this really cool HTML helper method for generating any kind of list.

public static class RazorExtensions {
    public static HelperResult List<T>(this IEnumerable<T> items, 
      Func<T, HelperResult> template) {
        return new HelperResult(writer => {
            foreach (var item in items) {

This List method accepts a templated Razor delegate, so we can call it like so.

  var items = new[] { "one", "two", "three" };


As I mentioned earlier, notice that the argument to this method, <span class="asp">@</span>&lt;li><span class="asp">@</span>item&lt;/li> is automatically converted into a Func&lt;dynamic, HelperResult> which is what our method requires.

Now this List method is very reusable. Let’s use it to generate a table of comic books.

    var comics = new[] { 
        new ComicBook {Title = "Groo", Publisher = "Dark Horse Comics"},
        new ComicBook {Title = "Spiderman", Publisher = "Marvel"}


This feature was originally implemented to support the WebGrid helper method, but I’m sure you’ll think of other creative ways to take advantage of it.

If you’re interested in how this feature works under the covers, check out this blog post by Andrew Nurse.

nuget,, mvc, code comments edit

Renaming a package ID is a potentially destructive action and one we don’t recommend doing. Why? Well if any other packages depend on your package, you’ve effectively broken them if you change your package ID.

For example, today I wanted to rename a poorly named package, MicrosoftWebMvc, to Mvc2Futures. What I ended up doing is recreating the same package with the new ID and uploading it. That way existing packages that depend on MicrosoftWebMvc aren’t broken.

But now, I have two packages that have the same functionality, but different IDs. Wouldn’t it be nice to eventually remove the old one? I guess I could if I knew that no other package had a dependency on it.

This is where the benefit of having an OData service over the packages in the gallery comes in quite useful. It allows us to construct ad-hoc queries we hadn’t accounted for in our API via an URL. Here’s the URL that shows me a list of all packages that depend on MicrosoftWebMvc.$filter=substringof(‘MicrosoftWebMvc’,%20Dependencies)%20eq%20true&$select=Id,Dependencies

Notice that we’re searching the Dependencies node for the substring “MicrosoftWebMvc” anywhere in it. If my package ID was “web”, this would not be a good query to run, so you might need to tweak it for your use case.

Also, this query only detects direct dependencies. It doesn’t detect transitive dependencies. However, in this case, that’s good enough for my needs.

With this list in hand, I can now approach the MvcContrib folks (who are the only ones that depend on it), and suggest they update their existing packages in place to point to the one with the new ID.

If they do this, am I safe to delete MicrosoftWebMvc?

Not necessarily.

I really need to think twice before I remove the MicrosoftWebMvcpackage because it’s already been downloaded 939 times. For those users who’ve installed it into their applications, they’ll never get updates for that package.

In this particular case, this is not a problem because we never plan to update the Mvc2Futures package. But for a package that’s more widely used and frequently updated, this would be a bigger concern.

In the meanwhile, what I will do is update MicrosoftWebMvc to be an empty package that depends on the correct package. That’s probably a good plan while I wait for packages that depend on it to update., mvc, razor comments edit

Within a Razor view, you have access to a base set of properties (such as Html, Url, Ajax, etc.) each of which provides methods you can use within the view.

For example, in the following view, we use the Html property to access the TextBox method.


Html is a property of type HtmlHelper and there are a large number of useful extension methods that hang off this type, such as  TextBox.

But where did the Html property come from? It’s a property of System.Web.Mvc.WebViewPage, the default base type for all razor views. If that last phrase doesn’t make sense to you, let me explain.

Unlike many templating engines or interpreted view engines, Razor views are dynamically compiled at runtime into a class and then executed. The class that they’re compiled into derives from WebViewPage. For long time ASP.NET users, this shouldn’t come as a surprise because this is how ASP.NET pages work as well.

Customizing the Base Class

HTML 5 (or is it simply “HTML” now) is a big topic these days. It’d be nice to write a set of HTML 5 specific helpers extension methods, but you’d probably like to avoid adding even more extension methods to the HtmlHelper class because it’s already getting a little crowded in there.


Well perhaps what we need is a new property we can access from within Razor. Well how do we do that?

What we need to do is change the base type for all Razor views to something we control. Fortunately, that’s pretty easy. When you create a new ASP.NET MVC 3 project, you might have noticed that the Views directory contains a Web.config file.

Look inside that file and you’ll notice the following snippet of XML.

    <host factoryType="System.Web.Mvc.MvcWebRazorHostFactory, 
    System.Web.Mvc, Version=, 
    Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
  <pages pageBaseType="System.Web.Mvc.WebViewPage">
      <add namespace="System.Web.Mvc" />
      <add namespace="System.Web.Mvc.Ajax" />
      <add namespace="System.Web.Mvc.Html" />
      <add namespace="System.Web.Routing" />

The thing to notice is the <pages> element which has the pageBaseType attribute. The value of that attribute specifies the base page type for all Razor views in your application. But you can change that value by simply replacing that value with your custom class. While it’s not strictly required, it’s pretty easy to simply write a class that derives from WebViewPage.

Let’s look at a simple example of this.

public abstract class CustomWebViewPage : WebViewPage {
  public Html5Helper Html5 { get; set; }

  public override void InitHelpers() {
    Html5 = new Html5Helper<object>(base.ViewContext, this);

Note that our custom class derives from WebViewPage, but adds a new Html5 property of type Html5Helper. I’ll show the code for that helper here. In this case, it pretty much follows the pattern that HtmlHelper does. I’ve left out some properties for brevity, but at this point, you can add whatever you want to this class.

public class Html5Helper {
  public Html5Helper(ViewContext viewContext, 
    IViewDataContainer viewDataContainer)
    : this(viewContext, viewDataContainer, RouteTable.Routes) {

  public Html5Helper(ViewContext viewContext,
     IViewDataContainer viewDataContainer, RouteCollection routeCollection) {
    ViewContext = viewContext;
    ViewData = new ViewDataDictionary(viewDataContainer.ViewData);

  public ViewDataDictionary ViewData {
    private set;

  public ViewContext ViewContext {
    private set;

Let’s write a simple extension method that takes advantage of this new property first, so we can get the benefits of all this work.

public static class Html5Extensions {
    public static IHtmlString EmailInput(this Html5Helper html, string name,       string value) {
        var tagBuilder = new TagBuilder("input");
        tagBuilder.Attributes.Add("type", "email");
        tagBuilder.Attributes.Add("value", value);
        return new HtmlString(tagBuilder.ToString());

Now, if we change the pageBaseType to CustomWebViewPage, we can recompile the application and start using the new property within our Razor views.


Nice! We can now start using our new helpers. Note that if you try this and don’t see your new property in Intellisense right away, try closing and re-opening Visual Studio.

What about Strongly Typed Views

What if I have a Razor view that specifies a strongly typed model like so:

@model Product
    ViewBag.Title = "Home Page";


The base class we wrote wasn’t a generic class so how’s this going to work? Not to worry. This is the part of Razor that’s pretty cool. We can simply write a generic version of our class and Razor will inject the model type into that class when it compiles the razor code.

In this case, we’ll need a generic version of both our CustomWebViewPage and our Html5Helper classes. I’ll follow a similar pattern implemented by HtmlHelper<T> and WebViewPage<T>.

public abstract class CustomWebViewPage<TModel> : CustomWebViewPage {
  public new Html5Helper<TModel> Html5 { get; set; }

  public override void InitHelpers() {
    Html5 = new Html5Helper<TModel>(base.ViewContext, this);

public class Html5Helper<TModel> : Html5Helper {
  public Html5Helper(ViewContext viewContext, IViewDataContainer container)
    : this(viewContext, container, RouteTable.Routes) {

  public Html5Helper(ViewContext viewContext, IViewDataContainer container, 
      RouteCollection routeCollection) : base(viewContext, container,
      routeCollection) {
    ViewData = new ViewDataDictionary<TModel>(container.ViewData);

  public new ViewDataDictionary<TModel> ViewData {
    private set;

Now you can write extension methods of Html5Helper<TModel> which will have access to the model type much like HtmlHelper<TModel> does.

As usual, if there’s a change you want to make, there’s probably an extensibility point in ASP.NET MVC that’ll let you make it. The tricky part of course, in some cases, is finding the correct point.

comments edit

It pains me to say it, but ASP.NET MVC 3 introduces a minor regression in routing from ASP.NET MVC 2. The good news is that there’s an easy workaround.

The bug manifests when you have a route with two consecutive optional URL parameters and you attempt to use the route to generate an URL. The incoming request matching behavior is unchanged and continues to work fine.

For example, suppose you have the following route defined:

        new { controller = "Home", action = "Index", 
            month = UrlParameter.Optional, day = UrlParameter.Optional }

Notice that the month and day parameters are both optional.

        new { controller = "Home", action = "Index", 
            month = UrlParameter.Optional, day = UrlParameter.Optional }

Now suppose you have the following view code to generate URLs using this route.

@Url.RouteUrl("by-day", new { month = 1, day = 23 })
@Url.RouteUrl("by-day", new { month = 1 })
@Url.RouteUrl("by-day", null)

In ASP.NET MVC 2 the above code (well actually, the equivalent to the above code since Razor didn’t exist in ASP.NET MVC 2) would result in the following URLs as you would expect:

  • /archive/1/23
  • /archive/1
  • /archive

But in ASP.NET MVC 3, you get:

  • /archive/1/23
  • /archive/1

In the last case, the value returned is nullbecause of this bug. The bug occurs when two or more consecutive optional URL parameters don’t have values specified for URL generation.

Let’s look at the workaround first, then we’ll dive deeper into why this bug occurs.

The Workaround

The workaround is simple. To fix this issue, change the existing route to not have any optional parameters by removing the default values for month and day. This route now handles the first URL where month and day was specified.

We then add a new route for the other two cases, but this route only has one optional month parameter.

Here are the two routes after we’re done with these changes.

        new { controller = "Home", action = "Index"}

        new { controller = "Home", action = "Index", 
            month = UrlParameter.Optional}

And now, we need to change the last two calls to generate URLs to use the by-month route.

@Url.RouteUrl("by-day", new { month = 1, day = 23 })
@Url.RouteUrl("by-month", new { month = 1 })
@Url.RouteUrl("by-month", null)

Just to be clear, this bug affects all the URL generation methods in ASP.NET MVC. So if you were generating action links like so:

@Html.ActionLink("sample", "Index", "Home", new { month = 1, day = 23 }, null)
@Html.ActionLink("sample", "Index", "Home", new { month = 1}, null)
@Html.ActionLink("sample", "Index", "Home")

The last one would be broken without the workaround just provided.

The workaround is not too bad if you happen to follow the practice of centralizing your URL generation. For example, the developers building ran into this problem as well during the upgrade to ASP.NET MVC 3. But rather than having calls to ActionLink all over their views, they have calls to methods that are specific to their application domain such as ForumDetailUrl. This allowed them to workaround this issue by updating a single method.

The Root Cause

For the insanely curious, let’s look at the root cause of this bug. Going back to the original route defined at the top of this post, we never tried generating an URL where only the second optional parameter was specified.

@Url.RouteUrl("by-day", new { day = 23 })

This call really should fail because we didn’t specify a value for the first optional parameter, month. If it’s not clear why it should fail, suppose we allowed this to succeed, what URL would it generate? /archive/23?  Well that’s obviously not correct because when a request is made for that URL, 23 will be interpreted to be the month, not the date.

In ASP.NET MVC 2, if you made this call, you ended up with /archive/System.Web.Mvc.UrlParameter/23. UrlParameter.Optional is a class introduced by ASP.NET MVC 2 which ships on its own schedule outside of the core ASP.NET Framework. What that means is we added this new class which provided this new behavior in ASP.NET MVC, but core routing didn’t know about it.

The way we fixed this in ASP.NET MVC 3 was to make the ToString method of UrlParameter.Optional return an empty string. That solved this bug, but uncovered a bug in core routing where a route with optional parameters having default values behaves incorrectly when two of them don’t have values specified during URL generation. Sound familiar?

In hindsight, I think it was a mistake to take this fix because it caused a regression for many applications that had worked around the bug. The bug was found very late in our ship cycle and this is just one of the many challenging decisions we make when building software that sometimes don’t work out the way you hoped or expected. All we can do is learn from it and let the experience factor into the next time we are faced with such a dilemma.

The good news is we have bugs logged against this behavior in core ASP.NET Routing so hopefully this will all get resolved in the next core .NET framework release.

nuget, open source, code comments edit

Today I’m pleased to announce the release of NuGet 1.1 to the VS Extension Gallery and CodePlex. If you have NuGet 1.0 installed, just launch the VS Extension Manager (via Tools | Extension Manager menu) and click on the Updates tab.

If you don’t see any updates, make sure to enable automatic detection of available updates.


If you are running VS 2010 SP1 Beta, you might run into the following error message when attempting to upgrade to NuGet 1.1 if you have an older version installed.

Visual Studio Extension Installer

The workaround is to simply uninstall NuGet and then install it from the VS Extension Gallery.

It turns out that our previous VSIX was signed with an incorrect certificate and our updated VSIX is signed with the correct certificate. VS 2010 SP1 now compares and verifies that the certificates of the old and new VSIX match during an upgrade.

If you don’t have NuGet installed, click the Online tab and type in “NuGet” (sans quotes) to find it.


The VSIX and updated command line tool (used to create and publish packages) is also available on

What’s New in 1.1?

Much of the work in this release was focused on bug fixes. Now that supports directly linking to filtered views of the issue tracker, I can provide you a link to all the issues fixed in 1.1. Smile

In this post, I’ll highlight some of the new features.

Recent Packages Tab

One of the first changes you might notice is that we have a new tab in the dialog that shows packages that you’ve installed recently. Click the screenshot below for a larger view.


The recent packages shows the last 20 packages that you’ve directly installed. This often comes in handy when you tend to use the same packages over and over again in multiple projects. Right now, the list simply shows the most recently used, but there has been discussion about perhaps changing the behavior to sort by the packages used most often. Feel free to chime in if you want the behavior changed.

By the way, you can also use the Powershell within the Package Manager Console to get this same information with the –Recent flag to Get-Package.


Progress Bar During Installation

When you install a package, you’ll now notice a progress bar dialog that shows up with output from installing the package.


The dialog is meant to give an indication of progress, but also gets out of your way immediately when the installation is complete so you’re not stuck clicking a bunch of Close buttons. But what happens if you actually want to review that output?

Package Manager Output Window

NuGet 1.1 also posts that output to the Output window now. When you go to the Output window, you’ll need to select output from the Package Manager to see that output as in the screenshot.


This allows you to review what changes a package made at your leisure after the fact.

Dependency Resolution Algorithm

NuGet 1.1 includes an update to our dependency resolution algorithm which is described in David Ebbo’s blog post on this topic in the section titled “NuGet 1.1 twist”.

Support for F# Project Types

If you are using F#, this one’s for you.

PowerShell Improvements

Thanks to our newest core contributor, Oisin Grehan a PowerShell MVP who really knows his stuff, NuGet 1.1 has a lot of improvements to the PowerShell Console and scripts. I have to admit, a lot of it is over my head as I’m no PowerShell guru, but we’re now much more compliant with PowerShell conventions. Or so I’ve been told. Oisin has been driving a lot of improvements with our PowerShell support.

We also now execute commands within the Powershell Console asynchronously. This means that a long running command won’t freeze the rest of Visual Studio while it runs.

And many others!

There were a lot of other tweaks, bug fixes, and minor improvements that were not worth mentioning here, but they are all listed in our release notes.

Breaking Changes?

There are some minor changes that hopefully won’t break 99.9% of you. If you recall, we made our PowerShell scripts fit with PowerShell conventions. If you have a package that calls one of these methods, your package might need to be updated.Here’s the list of changes we made:

  • Removed List-Package. Use Get-Package instead.
  • Get-ProjectNames was removed. Use Get-Project instead and examine the Name property.
  • Add-BindingRedirects was renamed to Add-BindingRedirect.

What’s next?

Our hope is to have a monthly point release, though we may adjust some iterations to be longer as needed. To see what we’re planning for the 1.2 release, check out this link of issues for 1.2 (note that by the time you read this, some of these features might already be implemented). We’re constantly refining our planning so nothing is set in stone.

For a small taste of what’s coming in 1.2, check out this video by David Ebbo showing a streamlined workflow for creating packages.

Get Involved!

I bet many of you have some great ideas on what we should and shouldn’t do for NuGet. We’d love to have you come over and share your great ideas in our discussion list. Or if you’re looking for other ways to contribute, check out our guide to contributing to NuGet., nuget, open source comments edit

Over a decade ago, Tim Berners-Lee, creator of the World Wide Web instructed the world know that cool URIs don’t change with what appears to be a poem, but it doesn’t rhyme and it’s not haiku.

What makes a cool URI? \ A cool URI is one which does not change. \ What sorts of URI change? \ URIs don’t change: people change them.

In a related article, URL as UI, usability expert Jakob Nielsen lists the following criteria for a usable site:

  • a domain name that is easy to remember and easy to spell
  • short URLs
  • easy-to-type URLs
  • URLs that visualize the site structure
  • URLs that are “hackable” to allow users to move to higher levels of the information architecture by hacking off the end of the URL
  • persistent URLs that don’t change

The permanence of URLs is a fundamental trait of the web that seems to run counter to one of the benefits of using a feature like ASP.NET Routing. For example, one benefit of routing is you can change a route from {controller}/{action}/{id} to {controller}/{id}/{action} and have every URL in your site corresponding to that route automatically be updated.

This is very nice during development when you’re still fleshing out your URLs and haven’t committed to anything, but once you’ve published your site, changing a route URL violates the sacred trait of URL permanence.

This is exactly where I find myself with Subtext. All of our existing URLs end with the .aspx extension, a practice which Jon Udell convincingly argued is harmful. In the upcoming version of Subtext, we’re moving to extensionless URLs by building upon the great support built into ASP.NET 4 and Routing.

I could simply change our routes to remove the .aspx extension, but that would break nearly every existing URL in every blog running on Subtext. So much for URL permanence, right?

There’s a Better Way

Rather than changing routes, what I really want is a way to simply redirect the existing route to a new route. This is pretty easy, but there are a few caveats to keep in mind that make it non-trivial.

  1. Since you don’t want to generate URLs for the old route, the legacy route should never be selected for URL generation. It’s only for matching incoming requests.
  2. The legacy route should be registered after the new URL to ensure it doesn’t accidentally match and supersede the new URL.

I wrote a library that provides a RedirectRoute and a simple extension method for registering a RedirectRoute that satisfies these conditions. Let’s look at an example of how it would be used.

Let’s suppose we have the following route defined and the site has been published to the web..

routes.MapRoute("old", "foo/{controller}/{action}/{id}");

But later, we decide we want all such URLs to start with /bar instead and we want to re-order the id and action segments of the URL.

Here’s an example of how we can do that using this new library.

var route = routes.MapRoute("new", "bar/{controller}/{id}/{action}");
routes.Redirect(r => r.MapRoute("old", "foo/{controller}/{action}/{id}"))  .To(route);

This snippet registers the new route and passes that route to the RedirectRoute that was returned by a call to the Redirect extension method. The RedirectRoute delegates to the old route to match incoming requests. With this in place, every request matching the old route will be redirected to the new route.

Thus a request for /foo/home/index/123 will be redirected to /bar/home/123/index.

Why The Lambda Expression?

To fully understand what’s going on under the hood, I need to explain why the API takes in a lambda expression rather than simply taking in two routes, old route and new route.

Let’s suppose that the API did just that, simply accepted two routes. Here’s what a naïve attempt to use the method might look like.

var new = routes.MapRoute("new", "bar/{controller}/{id}/{action}");
var old = routes.MapRoute("new", "foo/{controller}/{action}/{id}");

Hopefully it’s immediately apparent why this is not good. The old route is mapped before the redirect route. So the redirect route will never be matched. 

The MapRoute extension method not only creates a route, but it adds it to the route collection. So we could have manually created the route, but that’s a pain if you’re already using the MapRoute method to create the route. Or, we could have done this:

var new = routes.MapRoute("new", "bar/{controller}/{id}/{action}");
var throwAway = new RouteCollection();
var old = throwAway.MapRoute("new", "foo/{controller}/{action}/{id}");

Requiring the user of the API to create a throwaway route collection is ugly when the API itself could do it for you. Hence the lambda expression argument to Redirect. Internally, the method creates a throwaway route collection and calls the expression against that instead of against the main route collection.

Implementation Details

I won’t post the full source here, but the implementation details are pretty simple. Here’s the implementation of GetRouteData which is the method called when matching incoming requests.

public override RouteData GetRouteData(HttpContextBase httpContext) {
    // Use the original route to match
    var routeData = SourceRoute.GetRouteData(httpContext);
    if (routeData == null) {
        return null;
    // But swap its route handler with our own
    routeData.RouteHandler = this;
    return routeData;

Notice that I use the source route, which is the old route passed into the redirect route, to match the request, but I swap the route handler with the redirect route. RedirectRoute also implements IRouteHandler. It was a little implementation shortcut I took which happens to work fine in this case.

The implementation of GetVirtualPath is even simpler.

public override VirtualPathData GetVirtualPath(RequestContext requestContext  , RouteValueDictionary values) {
    // Redirect routes never generate an URL.
    return null;

We never want to generate a URL to the old route, so this method always returns null.

As mentioned, RedirectRoute implements IRouteHandler, so we should look at its implementation.

public IHttpHandler GetHttpHandler(RequestContext requestContext) {
  var requestRouteValues = requestContext.RouteData.Values;

  var routeValues = AdditionalRouteValues.Merge(requestRouteValues);

  var vpd = TargetRoute.GetVirtualPath(requestContext, routeValues);
  string targetUrl = null;
  if (vpd != null) {
    targetUrl = "~/" + vpd.VirtualPath;
    return new RedirectHttpHandler(targetUrl, Permanent, isReusable: false);
  return new DelegateHttpHandler(    httpContext => httpContext.Response.StatusCode = 404, false);

Notice that we make use of the DelegateHttpHandler which is something I wrote about a while ago.

Where to get it?

All the code I showed here is now part of the RouteMagic library I blogged about recently. I’ve updated the package so all you need to do is Install-Package RouteMagicwithin NuGet., code, mvc, open source comments edit

Over the past couple of years, I’ve written several blog posts on ASP.NET Routing where I provided various extensions to routing. Typically such blog posts included a zip download of the binaries and source code to allow readers to easily try out the code.

But that’s always been a real pain and most people don’t bother. But now, there’s a better way to share such code. Moving forward, I’ll be using NuGet packages as a means of sharing my code samples.

In the case of my routing extensions, I’ve compiled them into a solution I call RouteMagic (source is available on GitHub). This solution includes two packages, RouteMagic.Mvc (extensions specific to ASP.NET MVC Routing) and RouteMagic (more general ASP.NET Routing extensions). The RouteMagic.Mvc package depends on the RouteMagic package.

These packages are available in the NuGet feed!

After installing the RouteMagic.Mvc package, you’ll have the following  features available to you.

The source code for the solution contains the following projects:

  • RouteMagic
  • RouteMagic.Mvc
  • RouteMagic.Demo.Web (ASP.NET MVC Web application used to demo these features)
  • UnitTests

This is just a pet project I put together based on various blog posts I’ve written. I’d love to see some of these ideas eventually make it into the Framework. But until then, you’ll probably see these things make it into Subtext for sure!, mvc comments edit

Ni hao ma!

Hot on the heels of the RTM release of ASP.NET MVC 3, we now have localized versions of ASP.NET MVC in 9 languages! The installation links within the Web Platform Installer was updated. If you want to download the installer yourself, you can go to the English download page and select your language or click on one of the nine languages below:

If you speak one of these nine languages, you can now develop with ASP.NET MVC in your native language. Salud!

nuget comments edit

Last night I got a little treat in the mail from the kind folks at StickerMule. I really appreciate how they support open source projects with such great stickers.

NuGet-Stickers-550x365 Look at all those little NuGets!

Just in time as I have a few events I’ll be going to where I can hand some out such as Web Camps Argentina/Brazil, the MVP Summit, and if I’m selected, Mix 2011.

After that, I need to figure out the best way to give the rest out since I won’t be travelling a whole lot this year. We’ll need to have a Nerd Dinner or something. I’ll give some to Scott Hanselman since he travels a lot too. mvc, open source, nuget comments edit

For those of you who enjoy learning about a technology via screencast, I’ve recorded a video to accompany and complement this blog post. The screencast shows you what this package does, and the blog post covers more of the implementation details.

A key feature of any package manager is the ability to let you know when there’s an update available for a package and let you easily install that update.

For example, when we deployed the release candidate for NuGet, the Visual Studio Extension Manager displayed the release in the Updates section.

Extension Manager Displaying NuGet as an Available

Likewise, NuGet lets you easily see updates for installed packages. You can either run the List-Package –Updates command:


Or you can click on the Updates node of the Add Package dialog:


This feature is very handy when using Visual Studio to develop software such as Subtext, an open source blog engine I run in my spare time. But I started thinking about the users of Subtext and the hoops they jump through to upgrade Subtext itself.

Wouldn’t it be nice if Subtext could notify users when a new version is available and let them install it directly from the admin section of the running website completely outside of Visual Studio? Why yes, that would be nice.

NuGet to the Rescue!

Well my friends, that’s where NuGet comes into play. While most people know NuGet as a Visual Studio extension for pulling in and referencing libraries in your project, there’s a core API that’s completely agnostic of the hosting environment whether it be Visual Studio, PowerShell, or other. That core API is implemented in the assemly, NuGet.Core.dll.

This assembly allows us to take advantage of many of the features of NuGet outside of Visual Studio such as within a running web site!

The basic concept is this:

  1. Package up the first version of a website as a NuGet package.
  2. Install this package in the website itself. I know, crazy talk, right?
  3. Add a custom NuGet client that runs inside the website and checks for updates to the one package that’s installed.
  4. When the next version of the website is ready, package it up and deploy it to the package feed for the website. Now, the users of the website can be notified that an update is available.s

I should point out a brief note about step #2, because this is going to be confusing. When I say install the package in the website, I mean to contrast that with installing a package into your Web Application Project for the website.

When you install a package into your Web Application Project, you use the standard NuGet client within Visual Studio. But when you deploy your website, the custom NuGet client within the live website will install the website package into a different location. In the example I’ll show you, that location is within the App_Data\packages folder.

The AutoUpdate Package

Earlier this week, I gave an online presentation to the Community For MVC (C4MVC) user’s group on NuGet. During that talk I demonstrated a prototype package I wrote called AutoUpdate. This package adds a new area to the target website named “Installation”. It also adds a nuspec file to the root of the application to make it easy to package up the website as a NuGet Package.

The steps to use the package are very easy.

  1. Install-Package AutoUpdate.
  2. In Web.config, modify the appSetting PackageSource to point to your package source. In my demo, I just pointed it to a folder on my machine for demonstration purposes. But this source is where you would publish updates for your package.
  3. In the Package Console, run the New-Package script (This creates packages up the website in a NuPkg file).
  4. Copy the package into the App_Data\Packages folder of the site.
  5. When you are ready to publish the next version as an update, increment the version number in the nuspec file and run the New-Package script again.
  6. Deploy the updated package to the package source.
  7. Now, when your users visit /installation/updates/check within the web site, they’ll be notified that an update is available and will be able to install the update.

The Results

Lets see the results of installing the AutoUpdate package and I’ll highlight some of the code that makes the package work. The following screenshot shows a very basic sample application I wrote.


The homepage here has a link to check for updates which links to an action within the area installed by the AutoUpdate package. That action contains the logic to check for updates for this application’s package.

Clicking on that link requires me to login first and then I get to this page:


As I mentioned in the steps before, I packaged up the first version of the application as a package and “installed” it into the App_Data folder.

That yellow bar above is the result of an asynchronous JSON request to see if an update is available. It’s a little redundant on this page, but I could have it show up on every page within the admin as a notification.

Under the Hood

Let’s take a look at the controller that responds to that asynchronous request.

public ActionResult Check(string packageId) {
  var projectManager = GetProjectManager();
  var installed = GetInstalledPackage(projectManager, packageId);
  var update = projectManager.GetUpdate(installed);

  var installationState = new InstallationState {
    Installed = installed,
    Update = update

  if (Request.IsAjaxRequest()) {
    var result = new { 
      Version = (update != null ? update.Version.ToString() : null), 
      UpdateAvailable = (update != null)
    return Json(result, JsonRequestBehavior.AllowGet);

  return View(installationState);

The logic here is pretty straightforward. We grab a project manager. We then grab a reference to the current installed package representing this application. And then we check to see if there’s an update available. If there isn’t an update, the GetUpdate method returns false. There’s a couple of methods here that I wrote we need to look at.

The first method very simply retrieves a project manager. I encapsulated it into a method since I call it in a couple different places.

private WebProjectManager GetProjectManager() {
  string feedUrl = @"D:\dev\hg\AutoUpdateDemo\test-package-source";
  string siteRoot = Request.MapPath("~/");

  return new WebProjectManager(feedUrl, siteRoot);

There’s a couple things to note here. I hard coded the feedUrl for demonstration purposes to point to a directory on my machine. This is a nice demonstrations that NuGet can simply treat a directory containing packages as a package source.

For your auto-updating web application, that should point to a custom feed you host specifically for your website. Or, point it to the official NuGet feed and put your website up there. It’s up to you.

This method returns an instance of WebProjectManager. This is a class that I had to copy from the System.Web.WebPages.Administration.dll assembly because it’s marked internal. I don’t know why it’s internal, so I’ll see if we can fix that. It’s not my fault so please direct your hate mail elsewhere. Smile

What is the web project manager? Well the WebMatrix product which includes the ASP.NET Web Pages framework includes a web-based NuGet client for simple web sites. This allows packages to be installed into a running website. I’m just stealing that code and re-purposing it for my own needs.

Now, we just need to use the project manager to query the package source to see if there’s an update available. This is really easy.

private IPackage GetInstalledPackage(WebProjectManager projectManager,     string packageId) {
  var installed = projectManager.GetInstalledPackages("AutoUpdate.Web")    .Where(p => p.Id == packageId);

  var installedPackages = installed.ToList();
  return installedPackages.First();

What’s really cool is that we can just send a LINQ query to the server because we’re running OData on the server, it’ll run that query on the server and send us back the packages that fulfill the query.

That’s all the code necessary to check for updates. The next step is to write an action method to handle the upgrade. That’s pretty easy too.

public ActionResult Upgrade(string packageId) {
  var projectManager = GetProjectManager();
  var installed = GetInstalledPackage(projectManager, packageId);
  var update = projectManager.GetUpdate(installed);

  if (Request.IsAjaxRequest()) {
    return Json(new { 
      Success = true, 
      Version = update.Version.ToString()
    }, JsonRequestBehavior.AllowGet);
  return View(update);

This code starts off the same way that our code to check for the update does, but instead of simply returning the update, we call projectManager.UpdatePackage on the update. That method call updates the website to the latest version.

The rest of the method is simply concerned with returning the result of the upgrade.

Try it Yourself

If you would like to try it yourself, please keep a one big caveat in mind. This is rough proof of concept quality code. I hope to shape it into something more robust over time and publish it in the main package feed. Until then, I’ll post it here for people to try out. If there’s a lot of interest, I’ll post the source on

So with that in mind, give the AutoUpdate package a try

install-package AutoUpdate

and give me some feedback!

UPDATE: I upgraded the project to target ASP.NET MVC 4 and posted the source on GitHub. I have no idea if it still works, so please do submit pull requests if you find bugs you would like to have fixed., mvc, code, open source, nuget comments edit

The changing of the year is a time of celebration as people reflect thoughtfully on the past year and grow excited with anticipation for what’s to come in the year ahead.

Today, there’s one less thing to anticipate as we announce the final release of ASP.NET MVC 3 and NuGet 1.0!

double-rainbow \ Oh yeah, this never gets old.

Install it via Web Platform Installer or download the installer directly to run it yourself.

Here are a few helpful resources for learning more about this release:

Those links will provide more details about what’s new in ASP.NET MVC 3, but I’ll give a quick bullet list of some of the deliciousness you have to look forward to. Again, visit the links above for full details.

  • Razor view engine which provides a very streamlined syntax for writing clean and concise views.
  • Improved support for Dependency Injection
  • Global Action Filters
  • jQuery based Unobtrusive Ajax and Client Validation.
  • ViewBag property for dynamic access to ViewData.
  • Support for view engine selection in the New Project and Add View dialog
  • And much more!

For those of you wishing to upgrade an ASP.NET MVC 2 application to ASP.NET MVC 3, check out Marcin Dobosz’s post about our ASP.NET MVC 3 Projct upgrader tool. The tool itself can be found on our CodePlex website.

NuGet 1.0 RTM

Also included in this release is the 1.0 release of NuGet. I’ll let you in on a little secret though, if you upgraded NuGet via the Visual Studio Extension Gallery, then you’ve been running the 1.0 release for a little while now.

If you already have an older version of NuGet installed, the ASP.NET MVC 3 installer cannot upgrade it. Instead launch the VS Extension manager (within Visual Studio go to the Tools menu and select Extension Manager) and click on the Updates tab.

Just recently we announced the Beta release of our NuGet Gallery. Opening the door to the gallery will make it very easy to publish packages, so what are you waiting for!?

At this point I’m obligated to point out that everything about NuGet is open source and we’re always looking for contributors. If you’re interested in contributing, but are finding impediments to it, let us know what we can improve to make it easier to get involved. Here’s the full list of OSS projects that make up the NuGet client and the server piece:

Show Me The Open Source Code!

As we did with ASP.NET MVC 1.0 and ASP.NET MVC 2, the source for the ASP.NET MVC 3 assembly is being released under the OSI certified Ms-PL license. The Ms-PL licensed source code is available as a zip file at the download center.

If you’d like to see the source code for ASP.NET Web Pages and our MVC Futures project, we posted that on too.

What’s Next?

So what’s next? Well you can probably count as well as I can, so it’s time to start getting planning for ASP.NET MVC 4 and NuGet 2.0 in full gear. Though this time around, with NuGet now available, we have the means to easily distribute a lot of smaller releases throughout the year as packages, with the idea that many of these may make their way back into the core product. I’m sure you’ll see a lot of experimentation in that regard.

nuget, open source comments edit

As David Ebbo blogged today, the NuGet Gallery is now open to the public. The goal of the NuGet Gallery is to be the hub for NuGet users and package authors alike. Users should be able to search and discover packages with detailed information on each one and eventually rate them. Package authors can register for an API key and upload packages.

We’re not quite where we want to be with the gallery, but we’re moving in the right direction. If you want to see us get there more quickly, feel free to lend a hand. The gallery is running on fully open source code!

In this blog post, I wanted to cover step by step what it takes to create and upload a package.

Create Your Package

Well the first step is to create a package so you have something to upload. If you’re well acquainted with creating packages, feel free to skip this section, but you may learn a few tips if you stick with it.

I’ll start with a simple example that I did recently. The XML-RPC.NET library by Charles Cook is very useful for implementing XML-RPC Services and clients. It powers the MetaWeblog API support in Subtext. As a courtesy, I recently asked Charles if he would mind if I created a NuGet package for his library for him, to which he said yes!

So on my machine, I created a folder named after the latest 2.5 release, xmlrpcnet.2.5.0. Here’s the directory structure I ended up with.


By convention, the lib folder is where you place assemblies that will get added as referenced assemblies to the target project when installing this package. Since this assembly only supports .NET 2.0 and above, I put it in the net20 subfolder of the lib folder.

The other required file is the .nuspec file, which contains the metadata used to build the package. Let’s take a look at the contents of that file.

<?xml version="1.0" encoding="utf-8"?> 
    <authors>Charles Cook</authors> 
    <owners>Phil Haack</owners>
    <description>A client and server XML-RPC library for .Net.</description> 
    <tags>xml-rpc xml rpc .net20 .net35 .net40</tags>

There’s a couple of things I want to call out here. Notice that I specified Charles Cook in the authors element, but put my own name in the owners element. Authors represent the authors of the library within the package, while the owner typically represents the person who created the package itself. This allows people to know who to contact if there’s a problem with the package vs a problem with the library within the package.

In general, we hope that most of the time, the authors and the owners are one and the same. For example, someday I’d love to help Charles take ownership of his packages. Until that day, I’m happy to create and upload them myself.

If somebody creates a package for a library that you authored and uploads it to NuGet, assume it’s a favor they did to get your library out there. If you wish to take ownership, feel free to contact them and they can assign the packages over to you. This is the type of thing we’d like to see resolved by the community and not via some policy rules on the gallery site. This is a case where the gallery could do a lot to make this sort of interaction easier, but does not have such features in place yet.

With this in place, it’s time to create the package. To do that, we’ll need the NuGet.exe console application. Copy it to a utility directory and add it to your path, or copy it to the parent folder of the package folder.


Now, open a command prompt and navigate to the directory and run the nuget pack command.

nuget pack path-to-nuspec-file

Here’s a screenshot of what I did:


Pro tip: What I really did was add a batch file I call build.cmd in the same directory that I put the NuGet.exe file. The contents of the batch file is a single line:

for /r %%x in (*.nuspec) do nuget pack "%%x" -o d:\packages\

What that does is run the nuget pack command on every subdirectory of the current directory. I have a folder that contains multiple packages that I’m working on and I can easily rebuild them all with this batch file.

Ok, so now we have the package, let’s publish it! But first, we have to create an account on the NuGet Gallery website.

Register and Upload

The first step is to register for an account at Once you have an account, click on the Contribute tab. This page gives you several options for managing packages (click to enlarge).


To upload your package, click on the Add New Package link.


Notice there’s two options. At this point, you can simply browse for the package you created and upload it and you’re done. In a matter of a few minutes, it should appear in the public feed.

The second option allows you to host your package file in a location other than the NuGet gallery such as, Google Code, etc. Simply enter the the direct URL to the package and when someone tries to install your package, the NuGet client will redirect the download request to the external package URL.

Submit From The Command Line

Ok, that’s pretty easy. But you’re a command line junky, right? Or perhaps you’re automating package submission.

Well you’re in luck, it’s pretty easy to submit your package directly from the command line. But first, you’re going to need an API key.

Visit the My Account page ( and make a note of your API key (click image below to enlarge it).


Be sure to keep that API key secret! Don’t give it out like I just did. If you do happen to accidentally leak your API key, you can click the Generate New Key button, again like I just did. You didn’t really think I’d let you know my API key, did you?

Now, using the same NuGet.exe command line tool we downloaded earlier, we can push the package to the gallery using the nuget push command.

nuget push path-to-nupkg api-key –source

Here’s a screenshot of the exact command I ran.


Shoot! There I go showing off my secret API key again! I better regenerate that.

As you can see, this command uploaded my package and published it to the feed. I can login and visit the Manage My Contributions page to see this package and even make changes to it if necessary.

Moving Forward

We’re still working out the kinks in the site and hopefully, by the time you read this blog post, this particular issue will be fixed. Also, we’re planning to update the NuGet.exe client and make the NuGet gallery be the default source so that the –source flag is not required.

As David mentioned, the site was primarily developed as a project by the Nimble Pros in a very short amount of time. There’s two major components to the site. There’s the front-end Orchard Gallery built as an Orchard module. This powers the gallery website that you see when you visit There’s also the back-end gallery server which hosts the OData feed used to browse and search for packages as well as the WCF service endpoint for publishing packages.

Each of these components are open source projects which means if you really wanted to, you could take the code and host your own gallery website. Orchard will be using the same code to host its own gallery of Orchard modules.

Also, these projects accept contributions! I personally haven’t spent much time in the code, but I hope to find some free time to chip in myself. mvc,, code comments edit

In part 1 of this series, we looked at the scenario for grouping routes and how we can implement matching incoming requests with a grouped set of routes.

In this blog post, I’ll flesh out the implementation of URL Generation.

Url Generation Implementation

URL generation for a group route is tricky, especially when using named routes because the individual routes that make up the group aren’t in the main route collection.

As I noted before, the only route that’s actually added to the route table is the GroupRoute. Thus if you supply a route name for one of the child routes (such as “r1”) during URL generation, you’ll get a null URL.

Interestingly enough, in this case, if you don’t use named routes when using URL generation, everything works just fine. However, since I heartily recommend using named routes all the time, I should cover that situation.

So what we need to do here is supply two route names during URL generation. One for the group route, and one for the child route. How do we supply the child route name? We’re going to have to supply it in the route values. Here’s an example of generating an URL in this manner:

@Html.RouteLink("Hello World Child", "group", new { __RouteName = "hello-world3" }) 

Note that the second parameter, “group”, refers to the route name for the GroupRoute that we registered. The route value __RouteName is passed into the GroupRoute so that it can look in its own collection of routes for the matching child route.

In the following code sample, I’ve highlighted the essential part of the URL generation logic within the GroupRoute class.

public override VirtualPathData GetVirtualPath(RequestContext 
    requestContext, RouteValueDictionary values) {
  string routeName = values.GetRouteName();
  var virtualPath = ChildRoutes.GetVirtualPath(requestContext, 
    routeName as string, values.WithoutRouteName());
  if (virtualPath != null) {
    string rewrittenVirtualPath = 
    string directoryPath = VirtualPath.WithoutTildePrefix(); // remove tilde
    rewrittenVirtualPath = rewrittenVirtualPath.Insert(0, 
    virtualPath.VirtualPath = rewrittenVirtualPath.Remove(0, 1);

  return virtualPath;

The code grabs the route name for the child route from the supplied route values. Notice that I’m using an extension method I wrote in my last blog post.

The block of code after the highlighted portion rewrites the virtual path back to the full virtual path for the parent GroupRoute. This ensures that the virtual path that’s eventually returned to the caller will actually work, since the individual routes within the group don’t have a clue that they’re within a group.

In a follow-up blog post, I’ll wrap up this series and provide access to the full source code. mvc,, code comments edit

I gave a presentation to another team at Microsoft yesterday on ASP.NET MVC and the Razor view engine and someone asked if there was a reference for the Razor syntax.

It turns out, there is a pretty good guide about Razor available, but it’s focused on covering the basics of web programming using Razor and inline pages and not just the Razor syntax.

So I thought it might be handy to write up a a really concise quick reference about the Razor syntax.

Syntax/Sample Razor Web Forms Equivalent (or remarks)
Code Block
  int x = 123; 
  string y = "because.";
  int x = 123; 
  string y = "because."; 
Expression (Html Encoded)
<span><%: model.Message %></span>
Expression (Unencoded)
<span><%= model.Message %></span>
Combining Text and markup
@foreach(var item in items) {
<% foreach(var item in items) { %>
  <span><%: item.Prop %></span>
<% } %>
Mixing code and Plain text
@if (foo) {
  <text>Plain Text</text> 
<% if (foo) { %> 
  Plain Text 
<% } %>
Using block
@using (Html.BeginForm()) {
  <input type="text" value="input here">
<% using (Html.BeginForm()) { %>
  <input type="text" value="input here">
<% } %>
Mixing code and plain text (alternate)
@if (foo) {
  @:Plain Text is @bar
Same as above
Email Addresses
Razor recognizes basic email format and is smart enough not to treat the @ as a code delimiter
Explicit Expression
In this case, we need to be explicit about the expression by using parentheses.
Escaping the @ sign
<span>In Razor, you use the 
@@foo to display the value 
of foo</span>
@@ renders a single @ in the response.
Server side Comment
This is a server side 
multiline comment 
This is a server side 
multiline comment
Calling generic method
Use parentheses to be explicit about what the expression is.
Creating a Razor Delegate
  Func<dynamic, object> b = 
@b("Bold this")
Generates a Func<T, HelperResult> that you can call from within Razor. See this blog post for more details.
Mixing expressions and text
Hello @title. @name.
Hello <%: title %>. <%: name %>.
Conditional attributes
<div class="@className"></div>
When className = null
When className = ""
<div class=""></div>
When className = "my-class"
<div class="my-class"></div>
Conditional attributes with other literal values
<div class="@className foo bar">
When className = null
<div class="foo bar"></div>
Notice the leading space in front of foo is removed.
When className = "my-class"
<div class="my-class foo bar">
Conditional data-* attributes.

data-* attributes are always rendered.
<div data-x="@xpos"></div>
When xpos = null or ""
<div data-x=""></div>
When xpos = "42"
<div data-x="42"></div>
Boolean attributes
<input type="checkbox"
  checked="@isChecked" />
When isChecked = true
<input type="checkbox"
  checked="checked" />
When isChecked = false
<input type="checkbox" />
URL Resolution with tilde
<script src="~/myscript.js">
When the app is at /
<script src="/myscript.js">
When running in a virtual application named MyApp
<script src="/MyApp/myscript.js">

Notice in the “mixing expressions and text” example that Razor is smart enough to know that the ending period is a literal text punctuation and not meant to indicate that it’s trying to call a method or property of the expression.

Let me know if there are other examples you think should be placed in this guide. I hope you find this helpful.

UPDATE 12/30/2012: I’ve added a few new examples to the table of new additions to Razor v2/ASP.NET MVC 4 syntax. Razor got a lot better in that release!

Also, if you want to know more, consider buying the Programming ASP.NET MVC 4 book. Full disclosure, I’m one of the authors, but the other three authors are way better.