, mvc comments edit

In May, we released a tools update for ASP.NET MVC 3 in nine languages other than English. Today I got the good news that ASP.NET MVC 3 documentation is also now available in those nine languages, which arguably is even more helpful to those learning and using ASP.NET MVC.

Our team is constantly working to improve the quality of our documentation and having docs available in multiple languages is a big part of that work.

Unfortunately, translation to Klingon is still not on the roadmap.

Update: For those wondering where the English documentation is, it’s here:

open source, nuget comments edit

The moon goes around the earth and when it comes up on the other side, Hark! There’s a new release of NuGet! Well, this time it was more like one and a half revolutions, but I’m happy nonetheless to announce the release of NuGet 1.4.

A big thank you goes out to the many external contributors who submitted patches to this release! Your enhancements are much appreciated!

I’ve written up much more details about what’s in this release in the NuGet 1.4 Release Notes, but I’ll highlight a few choice things in this blog post.

NuGet Self-Update Notification Check

One thing you may notice immediately if you’re running NuGet 1.3 today is that the NuGet dialog notifies you itself that there’s a new version of NuGet.

NuGet Update Check

Note: The check is only made if the Online tab has been selected in the current session.

This feature was actually added in NuGet 1.3, but obviously would not be visible until today, now that NuGet 1.4 is available.

Managing Packages Across The Solution

A lot of work in this release went into managing packages across the solution. If you’re a command-line junky, the Package Manager Console Update-Package commands now support updating all packages in all projects as well as a single package across all projects.

The NuGet dialog can also be launched at the solution level which makes it easy to choose a set of projects to install a package into, rather than installing a package into a project one at a time. This was a common request for those working on a large multi-project solution.

NuGet Project

What’s Next?

This blog post is just a tiny sampling of what’s new. Again, check out the release notes for more details.

We’re going to try better to have a roadmap of the next couple of releases hosted on the front page here: For now, it’s very high level and general because we really only fully plan one iteration ahead.

However, we do have an idea of some of the big themes we want to focus on:

  • Simple package creation: We constantly want to lower the bar for creating and sharing code from inside and outside of Visual Studio.
  • NuGet in the Enterprise:This includes CI scenarios outside of Visual Studio, authenticated feeds, etc.
  • Flexible packaging: Includes things like including assemblies that are not referenced but deployed and vice versa.
  • Developer Workflow: We’re looking at common workflows that don’t match our own expectations and how we can support them. This also includes workflows we do know about such as the use of pre-release packages etc.

In general though, I think we can sum up all of themes in one big theme: Make NuGet Better!

Get Involved!

If you have great ideas for NuGet, please get involved in the discussions. We try to be very responsive and we do accept external contributions as Joshua Flanagan learned and wrote about in his blog post, An opportunity for a viable .NET open source ecosystem.

Then, remembering my last experience, I figured I would at least start a discussion before giving up for the night. To my surprise, the next day it was turned into an issue – this isn’t just another Microsoft Connect black hole. After hashing out a few details, I went to work on a solution and submitted a pull request. It was accepted within a few days. Aha! This is open source. This is how its supposed to work. This works.

Onward to NuGet 1.5!

blogging, personal comments edit

No, I’m not talking about my mental age.

My son turned four this past week which means I’m four years into my world domination plan. One of the gifts we gave my son was a toolbox with plastic toys so we can train him on building the mega-lasers and fortresses needed to take over the world. Turns out that before you start dominating the world, you have to start taking baby steps. And then toddler steps. And then 4-year old running terror steps.

In these past four years, I’ve learned a lot. For example, you can get a four year old to believe anything. That’s come in useful as a tool for manipulating my child to do my bidding. We were at the mall one day and he asked about a picture of a zombie with rotting teeth and without skipping a beat, my wife and I told him that’s what happens when you don’t wash your face and brush your teeth. There’s still complaining when I brush his teeth, but he’s at the sink at “two” on a three count.

Meta Bloggling

The point of this Random Friday series was to get back into the flow of blogging. But I am concerned that my Blog will turn entirely into random Friday blog posts. I guess it’s incentive for me to try and post some substance once a week as well. Or turn the knob down a bit and make this an every-other random Friday. The Fridays in between would be perfectly ordered and predictable Fridays and not worth blogging.

Friday Appreciation

And for the weekly thing I appreciate, it’s the sport of Soccer. Or Football as the rest of the world calls it. It’s interesting to me how quickly my British friends jump on me when I call it “Soccer”.

Bloody ‘ell! It’s called Football you stupid Amurrrrrican.

Which is ironic because the name Soccer comes from Association Football, which was invented, where else? England. The term was shortened to “Asoc” which forms the basis of the the word Soccer. In the words of those cheesy Anti-Drug PSAs, I learned it by watching you!

My summer soccer season started this Monday and we won our first game 5 – 4. Sadly, we went from 1st place in our division in the Winter season to last place last spring, which means we were relegated to a lower division for the summer season. Hopefully we can pull ourselves back up because things are a bit chippier down here.

After each game, I’ve somehow become the chronicler of our great deeds and I write-up a game report I send out to my teammates full of timeless sports classics such as Boom Goes The Dynamite. The fact that I have no future in sports writing is pretty safe. I toyed with the idea of posting the write-ups to my blog, but I didn’t want to turn my blog solely into a collection of Random Friday write-ups and tales of old men playing Soccer.

I’m on vacation next week so things should be quiet for me here. Unless past behavior is any indication in which case I’ll blog a thousand technical posts. Thanks for reading. Smile, mvc comments edit

UPDATE: I have an example Really Empty project template up on GitHub you can look at. I improved on this technique a bit in that one.

When you create a new ASP.NET MVC 3 project, the new project wizard dialog contains several options for different MVC project templates:

There’s a lot of white space in that dialog. To many of you, all that unsullied territory smells like opportunity. When I talk about this dialog, I go to great pains to tell folks that, yes!, you too can extend that dialog and add your own project templates in there.

If you wanted to, you could have your own ASP.NET MVC 3 project template configured exactly the way you want. Hate the default template? Make your own!

The only problem is, I keep telling you that you can extend it, but sadly I never told you how. But that’s about to change!

I don’t expect that a large number of people will want to do this, which is one reason we haven’t spent a large amount of time making it easy (though that may change in the future). But for the few of you impatient masochists who want to add your own custom templates now, this blog post will walk you through the hacking around it takes to make it happen.

Imitation is the sincerest form of productivity

The easiest way to get started is to simply copy and modify an existing project template. For example, I looked in the following directory:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ProjectTemplates\CSharp\Web\1033

on my machine and stole *ahem* borrowed the project template named Note that the 1033 folder is for English (en-US) templates. For other languages, you may need to look in a different folder.

I then renamed it to and extracted the contents into a folder so I could make some modifications to its contents.


When you extract the contents, you’ll want to rename the .vstemplate file to match the name of the template you chose. In my case, I renamed MvcWebApplicationProjectTemplatev3.01.cshtml.vstemplate to MyProjectTemplate.cshtml.vstemplate.

Open up the .vstemplate file in NotePad and make sure to change the TemplateID element value to something unique.

You can change any of the contents of the template folder now, but be very careful to make sure that any additions or deletions of content are reflected in the .vstemplate file. That file is a manifest of all the files within the VSIX package that makes up the project template. Also make sure that the .csproj file reflects those changes as well, to ensure any new files you add to the template are properly referenced in the project.

Pre-installed NuGet packages

UPDATE: The upcoming NuGet 1.5 feature will provide support for this feature in a way that doesn’t require the following harsh warning. Marcin Dobosz has a blog post detailing the feature.

Warning: I probably shouldn’t show you this next section and some of my co-workers may chide me on this. But if you promise to be responsible and pay close attention to the information and context for that information I’m about to show you, I’ll do it anyways and trust you not to inundate us with support calls when this blows your hand off.

The ASP.NET MVC 3 Tools Update includes very limited support for project templates that include NuGet packages. We originally wanted it to be very extensible, but ran out of time and imposed some severe limitations on the feature, hence the caution.

If you scroll to the bottom of the .vstemplate file, you’ll notice the following section:

        <package id="jQuery" version="1.5.1" />
        <package id="jQuery.vsdoc" version="1.5.1" />
        <package id="jQuery.Validation" version="1.8.0" />
        <package id="jQuery.UI.Combined" version="1.8.11" />
        <package id="EntityFramework" version="4.1.10331.0" />
        <package id="Modernizr" version="1.7" />

That is the list of NuGet packages that the MVC 3 project template installs when you invoke the project template.

But as I mentioned, there are two major limitations:

  • The package must exist in the %ProgramFiles%\Microsoft ASP.NET\ASP.NET MVC 3\Packages folder. MVC 3 doesn’t go searching online for them.
  • The version attribute of the package in the <package> element is required and is an exact match.

If you are fine with these limitations, you can modify this section of your custom project template to install the NuGet packages you care about. Just make sure they exist in the MVC 3 packages folder like I mentioned.

Once you are done making your changes, zip up the contents of the folder with the same file name you had before.

Registering your project template

At this point, all you need to do is copy the project template to the right location and add the appropriate registry entries. For extra credit, you can write an installer (MSI) that does all this for you.

The place to copy your template is the same place I mentioned previously, C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ProjectTemplates\CSharp\Web\1033

Once the template is there, you’ll need to setup the correct registry settings.


Since I’m lazy, I put these registry settings in a .reg file to make it easy to install. You’ll just need to modify the settings within the .reg file to match your project template.


Windows Registry Editor Version 5.00

"Title"="My Project Template"
"Description"="This is the coolest project template EVAR MADE."



Windows Registry Editor Version 5.00

"Title"="My Project Template"
"Description"="This is the coolest project template EVAR MADE."


The important thing to note are the options in the second registry section:

  • Path – Relative path from the ProjectTemplates folder. For C# projects, enter “CSharp\\Web”. For VB.NET use “VisualBasic\\Web”
  • SupportsHTML5 –Whether or not the project template supports HTML5. If set to 1, then the HTML 5 checkbox is enabled. That checkbox sets a project template variable, $usehtml5$. You can look at the default /Views/Shared/_Layout.cshtml inside of MvcWebApplicationProjectTemplatev3.01.cshtml.zipfor an example of this.
  • SupportsUnitTests – This allows you to associate a unit test project template with your project template.
  • Template – the name of your project template file.

The last step is to run the command devenv /installvstemplates to force Visual Studio to recognize the project templates.

I wrote a batch file, install.bat, when combined with the .reg file, that automates these steps.

cd %~dp0
regedit.exe /s project-template.reg
xcopy "C:\Program Files (x86)\Microsoft Visual Studio   10.0\Common7\IDE\ProjectTemplates\CSharp\Web\1033" /Y
devenv /installvstemplates

For your convenience, I packaged up the necessary files in a zip file. Unzip the file, and run install.bat and you’ll see a new project template when you create a new ASP.NET MVC 3 project.


Pretty cool, eh?

By the way, I’m working on a book about ASP.NET MVC 3 with Brad Wilson, Jon Galloway, and K. Scott Allen. We’ve re-written large portions of the book in light of the new features that were released in ASP.NET MVC 3. If you’re interested, feel free to pre-order our book on!

humor, personal comments edit

It’s that time of year at Microsoft when managers are busily preparing reviews of their reports and preparing for the big stack ranking.

Yesterday, my manager sent out an email asking his reports to email him with their accomplishments in the past year to help jog his memory. This arms him with important information when he goes to the mat for us arguing why we’re more deserving of a higher ranking than some other manager’s sad report.

Here was my response. In the past year, I…

  • Escaped from a black hole. Twice. I forgot my jacket in there and had to go get it.
  • Discovered an albino polar bear.
  • Proved Fermat’s Last Theorem as well as his penultimate theorem.
  • Found Waldo. And made him change out of that ridiculous shirt and hat. Discovered he’s really Harry Potter.
  • Unified gravity and quantum mechanics while watching Jersey Shore to make it a challenge.
  • Invented cold fusion as well as luke warm fusion.
  • Passed the turing test using a computer made of legos.
  • Finished World of Warcraft on an Atari 2600.
  • Counted all the elements within an uncountable set of Hilbert spaces.
  • Hunted a magical unicorn with my bare hands. Drank its blood. And now I’m magical.

Not to be outdone, Steve Sanderson replied with the following:

Oh yeah? That’s nothing. I successfully submitted an expense claim using the online expenses tool.

Color me impressed!

Friday Appreciation

And for the weekly thing I appreciate, this week I appreciate the word hyperbole. It sounds like hyperbola, but is a totally different thing. Be sure not to confuse the two.

What I did above is hyperbole, while this is a hyperbola.


Have a nice weekend!, mvc, nuget, code comments edit

At the risk of getting punched in the face by my friend Miguel, I’m not afraid to admit I’m a fan of responsible use of dependency injection. However, for many folks, attempting to use DI runs into a roadblock when it comes to ASP.NET HttpModule.

In the past, I typically used “Poor man’s DI” for this. I wasn’t raised in an affluent family, so I guess I don’t have as much of a problem with this approach that others do.

However, when the opportunity for something better comes along, I’ll take it Daddy Warbucks. I was refactoring some code in Subtext when it occurred to me that the new ability to register HttpModules dynamically using the PreApplicationStartMethodAttribute could come in very handy.

Unfortunately, the API only allows for registering a module by type, which means the module requires a default constructor. However, as with many problems in computer science, the solution is another layer of redirection.

In this case, I wrote a container HttpModule that itself calls into the  the DependencyResolver feature of ASP.NET MVC 3 in order to find and initialize the http modules registered via your IoC/DI container. The approach I took happens to be very much similar to one that Mauricio Scheffer blogged about a while ago.

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.Mvc;
using HttpModuleMagic;
using Microsoft.Web.Infrastructure.DynamicModuleHelper;

[assembly: PreApplicationStartMethod(typeof(ContainerHttpModule), "Start")]
namespace HttpModuleMagic
  public class ContainerHttpModule : IHttpModule
    public static void Start()

    Lazy<IEnumerable<IHttpModule>> _modules 
      = new Lazy<IEnumerable<IHttpModule>>(RetrieveModules);

    private static IEnumerable<IHttpModule> RetrieveModules()
      return DependencyResolver.Current.GetServices<IHttpModule>();

    public void Dispose()
      var modules = _modules.Value;
      foreach (var module in modules)
        var disposableModule = module as IDisposable;
        if (disposableModule != null)

    public void Init(HttpApplication context)
      var modules = _modules.Value;
      foreach (var module in modules)

The code is pretty straightforward, though there’s a lot going on here. At the top of the class we use the PreApplicationStartMethodAttribute which allows the http module to register itself! Just reference the assembly containing this code and you’re all set to go. No mucking around with web.config!

Note that this code does require that you’re application has the following two assemblies in bin:

  1. System.Web.Mvc.dll 3.0
  2. Microsoft.Web.Infrastructure.dll 1.0

The nice part about this is after referencing this assembly, I can simply register the Http Modules using my favorite DI container and I’m good to go. For example, I installed the Ninject.Mvc3 package and added the following Subtext http module bindings:


There is one caveat I should point out. You’ll notice that when the container http module is disposed, Dispose is called on each of the registered http modules.

This could be problematic if you happen to register them in singleton scope. In my case, all of my modules are stateless and the Dispose method is a no-op, which in general is a good idea unless you absolutely need to hold onto state.

If your modules do hold onto state and need to be disposed of, you’ll have to be careful to scope your http modules appropriately. It’s possible for multiple instances of your http module to be created in an ASP.NET application.

DI for a Single Http Module

Just in case your DI container doesn’t support the ability to register multiple instances of a type (in other words, it doesn’t support the DependencyResolver.GetServices call), or it can’t handle the scoping properly and your http module holds onto state that needs to be disposed at the right time, I did write another class for registering an individual module, while still allowing your DI container to hook into creation of that one module.

In this case, you won’t be using DI to register the set of http modules. But you will be using it to create instances of the modules that you register.

Here’s the class.

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

namespace HttpModuleMagic
  public class ContainerHttpModule<TModule> 
    : IHttpModule where TModule : IHttpModule
    Lazy<IHttpModule> _module = new Lazy<IHttpModule>(RetrieveModule);

    private static IHttpModule RetrieveModule()
      return DependencyResolver.Current.GetService<IHttpModule>();

    public void Dispose()

    public void Init(HttpApplication context)

This module is much like the other container one, but it only wraps a single http module. You would register it like so:


In this case, you’d need to set up your own PreApplicationStartMethod attribute or use the WebActivator.

And of course, I created a little NuGet package for this.

Install-Package HttpModuleMagic

Note that this requires that you install it into an application with the ASP.NET MVC 3 assemblies.

personal comments edit

I’m reading through the archives of a blog where the author posts something random every Friday (yesterday was Thursday, and tomorrow is Saturday). His Friday posts are completely unrelated to the main theme and content of his blog.

I like that idea a lot. I don’t blog as much as I used to mostly because I feel the need to spend so much time on each blog post. A lot of the posts I write take a bit of research and experimentation before I’m ready to post them.

But a random thought? I can pull one of those out of my ascot any day of the week, and twice on Friday. But I’ll only do it once.

And yes, thanks for asking, but the thought has occurred to me that I already have another medium where I post random thoughts 7 days a week, Twitter (I’m @haacked on Twitter).

But my twist on this is that every Friday, I’ll post something random, funny, amusing, or whatever in this blog post, and I’ll use more than 140 characters but I’ll always end the post with something I appreciated either during the week, or in general.

This Friday’s random thought is about starting a random thought Friday blog series and whether this will end up being a one post series like the rest. So there, I’ve done that part.

And the thing I appreciate this past week is how nice it was to take a day off and spend it with my wife. Oh, and Instagram. I appreciate Instagram a lot. Perhaps too much. I’ll try easing off the Tilt-Shift from now on.


Here’s where I violate my wife’s privacy and post a picture of her on a ferry to Bainbridge Island on my blog. We had a really nice outing on Tuesday., mvc, code comments edit

When you build an ASP.NET MVC 3 application and are ready to deploy it to your hosting provider, there are a set of assemblies you’ll need to include with your application for it to run properly, unless they are already installed in the Global Assembly Cache (GAC) on the server.

In previous versions of ASP.NET MVC, this set of assemblies was rather small. In fact, it was only one assembly, System.Web.Mvc.dll,though in the case of ASP.NET MVC 1.0, if you didn’t have SP1 of .NET 3.5 installed, you would have also needed to deploy System.Web.Abstractions.dll and System.Web.Routing.dll.

But ASP.NET MVC 3 makes use of technology shared with the new ASP.NET Web Pages product such as Razor. If you’re not familiar with ASP.NET Web Pages and how it fits in with Web Matrix and ASP.NET MVC, read David Ebbo’s blog post, How WebMatrix, Razor, ASP.NET Web Pages, and MVC fit together.

If your server doesn’t have ASP.NET MVC 3 installed, you’ll need to make sure the following set of assemblies are deployed in the bin folder of your web application:

  • Microsoft.Web.Infrastructure.dll
  • System.Web.Helpers.dll
  • System.Web.Mvc.dll
  • System.Web.Razor.dll
  • System.Web.WebPages.Deployment.dll
  • System.Web.WebPages.dll
  • System.Web.WebPages.Razor.dll

In this case, it’s not as simple as looking at your list of assembly references and setting Copy Local to True as I’ve instructed in the past.

As you can see in the following screenshot, not every assembly is referenced. Not all of these assemblies are meant to be programmed against so it’s not necessary to actually reference**each of these assemblies. They just need to be available on the machine either from the GAC or in the bin folder.


But the Visual Web Developer team has you covered. They added a feature specifically for adding these deployable assemblies. Right click on the project and select Add Deployable Assemblies and you’ll see the following dialog.


When building an ASP.NET MVC application, you only need to check the first option. Ignore the fact that the second one says “Razor”. “ASP.NET Web Pages with Razor syntax”was the official full name of the product we simply call ASP.NET Web Pages now. Yeah, it’s confusing.

Note that there’s also an option for SQL Server Compact, but that’s not strictly necessary if you’ve installed SQL Server Compact via NuGet.

So what happens when you click “OK”?


A special folder named _bin_deployableAssemblies is created and the necessary assemblies are copied into this folder. Web projects have a built in build task that copies any assemblies in this folder into the bin folder when the project is compiled.

Note that this dialog did not add any assembly references to these assemblies. That ensures that the types in these assemblies don’t pollute Intellisense, while still being available to your deployed application. If you actually need to use a type in one of these assemblies, you’re free to reference them.

So here’s the kicker. If you’re building a web application, and you need an assembly deployed but don’t want it referenced and don’t want it checked into the bin directory, you can simply add this folder yourself and put your own assemblies in here.

If you’ve ever run into a problem where an ASP.NET MVC site you developed locally doesn’t work when you deploy it, this dialog may be just the ticket to fix it.

open source, nuget comments edit

Most developers I know are pretty anal about the formatting of their source code. I used to think I was pretty obsessive compulsive about it, but then I joined Microsoft and faced a whole new level of OCD (Obsessive Compulsive Disorder). For example, many require all using statements to be sorted and unused statements to be removed, which was something I never cared much about in the past.

There’s no shortcut that I know of for removing unused using statements. Simply right click in the editor and select Organize Usings > Remove and Sort**in the context menu.

SubtextSolution - Microsoft Visual Studio (Administrator)

In Visual Studio, you can specify how you want code formatted by launching the Options dialog via Tools> Options and then select the Text Editor node. Look under the language you care about and there are multiple formatting options providing hours of fun fodder for religious debates.


Once you have the settings just the way you want them, you can select the Edit > Advanced > Format Document (or simply use the shortcut CTRL + K, CTRL + D ) to format the document according to your conventions.

The problem with this approach is it’s pretty darn manual. You’ll have to remember to do it all the time, which if you really have OCD, is probably not much of a problem.

However, for those that keep forgetting these two steps and would like to avoid facing the wrath of nitpicky code reviewers (try submitting a patch to NuGet to experience the fun), you can install the Power Commands for Visual Studio via the Visual Studio Extension manager which provides an option to both format the document and sort and remove using statements every time you save the document.

I’m actually not a fan of having using statements removed on every save because I save often and it tends to remove namespaces containing extension methods that I will need, but haven’t yet used, such as System.Linq.

Formatting Every Document

Also, if you have a large solution with many collaborators, the source code can start to drift away from your OCD ideals over time. That’s why it would be nice to have a way of applying formatting to every document in your solution.

One approach is to purchase ReSharper, which I’m pretty sure can reformat an entire solution and adds a lot more knobs you can tweak for the formatting.

But for you cheap bastards, there are a couple of free approaches you can make. One approach is to write a Macro, like Brian Schmitt did. His doesn’t sort and remove using statements, but it’s a one line addition to add that.

Of course, the approach I was interested in trying was to use Powershell to do it within the NuGet Package Manager Console. A couple nights ago I was chatting with my co-worker and hacker extraordinaire, David Fowler, way too late at night about doing this and we decided to have a race to see who could implement it first.

I knew I had no chance unless I cheated so I wrote this monstrosity (I won’t even post it here I’m so ashamed). David calls it “PM code”, which in this case was well deserved as it was simply a proof of concept, but also because it’s wrong. It doesn’t traverse the files recursively. But hey, I was first! But I at least gave him the code needed to actually format the document.

It was very late and I went to sleep knowing in the morning, I’d see something elegant from David. I was not disappointed as he posted this gist.

He wrote a generic command named Recurse-Project that recursively traverses every item in every project within a solution and calls an action against each item.

That allowed him to easily write Format-Document which leverages Recurse-Project and automates calling into Visual Studio’s Format Document command.

function Format-Document {
    [parameter(ValueFromPipelineByPropertyName = $true)]
  Process {
    $ProjectName | %{ 
      Recurse-Project -ProjectName $_ -Action {
        if($item.Type -eq 'Folder' -or !$item.Language) {
        $win = $item.ProjectItem.Open('{7651A701-06E5-11D1-8EBD-00A0C90F26EA}')
        if ($win) {
          Write-Host "Processing `"$($item.ProjectItem.Name)`""

Adding Commands to NuGet Powershell Profile

Great! He did the work for me. So what’s the best way to make use of his command? I could add it to a NuGet package, but that would then require that I install the package first any time I wanted to use the package. That’s not very usable. NuGet doesn’t yet support installing PS scripts at the machine level, though it’s something we’re considering.

To get this command available on my machine so I can run it no matter which solution is open, I need to set up my NuGet-specific Powershell profile as documented here.

The NuGet Powershell profile script is located at:


The easiest way to find the profile file is to type $profile within the NuGet Package Manager Console. The profile file doesn’t necessarily exist by default, but it’s easy enough to create it. The following screenshot shows a session where I did just that.


The mkdir –force (split-path $profile) command creates the WindowsPowershell directory if it doesn’t already exist.

Then simply attempting to open the script in Notepad prompts you to create the file if it doesn’t already exist. Within the profile file, you can change PowerShell settings or add new commands you might find useful.

For example, you can cut and paste the code in David’s gist and put it in here. Just make sure to omit the first example line in the gist which simply prints all project items to the console.

When you close and re-open Visual Studio, the Format-Document command will be available in the NuGet Package Manager Console. When you run the command, it will open each file and run the format command on it. It’s rather fun to watch as it feels like a ghost has taken over Visual Studio.

The script has a Thread.Sleep call for 100ms to work around a timing issue when automating Visual Studio. It can take a brief moment after you open the document before you can activate it. It doesn’t hurt anything to choose a lower number. It only means you may get the occasional error when formatting a document, but the script will simply move to the next document.

The following screenshot shows the script in action.


With this in place, you can now indulge your OCD and run the Format-Document command to clean up your entire solution. I just ran it against Subtext and now can become the whitespace Nazi I’ve always wanted to be.

open source, personal comments edit

Almost two years ago, I announced the launch of, a blatant and obvious rip-off of the Let me Google that for you website.

The initial site was created by Maarten Balliauw and Juliën Hanssens in response to a call for help I made. It was just something we did for fun. I’ve been maintaining the site privately always intending to spend some time to refresh the code and open source it.

Just recently, I upgraded the site to ASP.NET MVC 3, refactored a bunch of code, and moved the site to AppHarbor.

Why AppHarbor?

I’ve heard such good things about how easy it is to deploy to AppHarbor so I wanted to try it out firsthand myself, and this small little project seemed like a perfect fit.

I had been working on the code in a private Mercurial repository so it was trivially easy for me to push it to a BitBucket repository. From there it’s really easy to integrate the BitBucket account with AppHarbor.

So now, my deployment workflow is really easy when working on this simple project:

  1. Make some changes and commit them into my local HG (Mercurial) repository. I have my local repository syncing to all my machines using Live Mesh.
  2. At some point, when I’m ready to publish the changes, I run the hg push command on my repository.
  3. That’s it! AppHarbor builds my project and if all the unit tests pass, it deploys it live.

I’m not planning to spend a lot of time on Let Me Bing That For You. It’s just a fun little side project that allows me to play around with ASP.NET MVC 3, jQuery, etc. If you want to look at the source, or contribute a patch, check it out on BitBucket.

nuget, open source comments edit

It’s a common refrain you hear when it comes to documentation for open source projects. It typically sucks! In part, because nobody wants to work on docs. But also in part because good documentation is challenging to write.

What is good documentation in the first place? The following is a list of some qualities that make for great documentation. This list is by no means complete. Good docs are…

  • Written for the right audience
  • Comprehensive and accurate
  • Easily browsable and searchable
  • Written in a clear and concise language
  • Laid out in a readable format
  • Versioned with the source code

While it’s challenging to write and maintain great documentation, my co-worker Matthew was up to the challenge of building a simple Markdown based system to help us manage our documentation. Read about our new docs site in his blog post, Introducing NuGet Docs: Community Driven Documentation.

Our goal in the long run is to have a great set of docs for NuGet with help from the community. So if you’re interested in helping out, please visit our NuGet Docs project page and let us know. It’s a separate repository with its own Mercurial repository so we can give a lot more people write access directly to the repository.

So please, if you’re looking for a low commitment easy way to get a toe in the waters with open source in general or with NuGet, consider helping us with our docs. It’s a great way to get started with OSS. It’s how I got my start a long time ago by contributing docs to RSS Bandit. mvc, comments edit

In April we announced the release of ASP.NET MVC 3 Tools Update which added Scaffolding, HTML 5 project templates, Modernizr, and EF Code First Magic Unicorn Edition.

Today, just shy of one month later I’m happy to announce that this release is now available in nine other languages via the Web Platform Installer (Web PI).

We’ve also included release notes translated into the nine languages as well.

The best way to install the language specific version of ASP.NET MVC 3 is via the Web Platform installer because it will chain in the full installer. If you install the language specific version directly from the Download Details page, you’ll need to run two installers, the full installer and then the language pack installer., mvc comments edit

ASP.NET MVC project templates include support for precompiling views, which is useful for finding syntax errors within your views at build time rather than at runtime.

In case you missed the memo, the following outline how to enable this feature.

  • Right click on your ASP.NET MVC project in the Solution Explorer
  • Select Unload Project in the context menu. Your project will show up as unavailableunavailable-project
  • Right click on the project again and select Edit ProjectName.csproj.

This will bring up the project file within Visual Studio. Search for the entry <MvcBuildViews> and set the value to true. Then right click on the project again and select Reload Project.

Compiling in a build environment

If you search for MvcBuildViews on the web, you’ll notice a lot of people having problems when attempting to build their projects in a build environment. For example, this StackOverflow question describes an issue when compiling MVC on a TFS Build. I had an issue when trying to deploy an ASP.NET MVC 3 application to AppHarbor.

It turns out we had a bug in our project templates in earlier versions of ASP.NET MVC that we fixed in ASP.NET MVC 3 Tools Update.

But if you created your project using an older version of ASP.NET MVC including ASP.NET MVC 3 RTM (the one before the Tools Update), your csproj/vbproj file will still have this bug.

To fix this, look for the following element within your project file:

<Target Name="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
  <AspNetCompiler VirtualPath="temp" PhysicalPath="$(ProjectDir)\..\$(ProjectName)" />

And replace it with the following.

<Target Name="MvcBuildViews" AfterTargets="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
  <AspNetCompiler VirtualPath="temp" PhysicalPath="$(WebProjectOutputDir)" />

After I did that, I was able to deploy my application to AppHarbor without any problems.

Going back to the StackOverflow question I mentioned earlier, notice that the accepted answer is not the best answer. Jim Lamb provided a better answer and is the one who provided the solution that we use in ASP.NET MVC 3 Tools Update. Thanks Jim!

nuget, code, open source comments edit

Not too long ago, I posted a survey on my blog asking a set of questions meant to gather information that would help the NuGet team make a decision about a rather deep change.

You can see the results of the survey here.

If there’s one question that got to the heart of the matter, it’s this one.


We’re considering a feature that would only allow a single package version per solution. As you can see by the response to the question, that would fit what most people need just fine, though there are a small number of folks that might run into problems with this behavior.

One variant of this idea would allow multiple package versions if the package doesn’t contain any assemblies (for example, a JavaScript package like jQuery).

Thanks again for filling out the survey. We think we have a pretty good idea of how to proceed at this point, but there’s always room for more feedback. If you want to provide more feedback on this proposed change, please review the spec here and post your thoughts in our discussion forum in the thread dedicated to this change.

The spec describes what pain point we’re trying to solve and shows a few examples of how the behavior change would affect common scenarios, so it’s worth taking a look at.

comments edit

On a personal level, NuGet has been an immensely satisfying project to work on. I’ve always enjoyed working on open source projects with an active community in my spare time, but being able to do it as part of my day job is really fulfilling.

And I don’t think I’m alone in this as evidenced by this tweet from a co-worker, Matt Osborn who was contributing to NuGet on his own time from the early days.

Matthew M. Osborn (osbornm) on Twitter - Google

A big part of the satisfaction comes from being able to collaborate with members of the community, aka you, in a deeper manner than before, which includes accepting contributions.

If you go to the OSS community site,, you can see a list of contributors to Nuget. As you might expect, the top five contributors are Microsofties who work on NuGet as part of their day job. But three of the top ten are external contributors from the community.

NuGet Contributors - Ohloh - Google

It looks like 21 of the 36 contributors are external. Take these numbers with a slight grain of salt because we use a distributed version control system and it appears some developers are counted twice because they used a different email address on a different computer.

Note to those developers! Create an account on and claim those check-ins! Ohloh will provide a merged view of your contributions.

Contributions come in all sizes.We’ve had folks come in and “scratch an itch” with single commits adding things like support for WiX or the .NET Micro Framework. Such commits form a key pillar of open source software as Linus Torvalds stated when discussing a Microsoft patch to Linux:

I agree that it’s driven by selfish reasons, but that’s how all open source code gets written! We all “scratch our own itches”.

While other contributions took a lot of work among multiple community members such as the work to fix Proxy issues within NuGet. We didn’t have the ability to test the wide range of proxy servers people had in the wild. Fortunately several folks in our forums worked on this and tested out daily builds till we got it working in Package Explorer. This will soon be rolled into NuGet proper. Thanks!

As with most open source projects, commits do not tell the full story of a community’s contributions to a project. In some cases, these folks were involved in a lot of design and verification work that ended up being perhaps one commit.

Our discussion boards are full of active participants telling us we’re doing it wrong, or doing it right, or what we need to do. And that’s great! The commitment of their time to help us shape a better project is greatly appreciated. Even those who come in and criticize the product are making a noteworthy contribution as they’ve taken the time to give us food for thought. As they say, indifference is worse than hate and we’ve found a lot of folks who are not indifferent.

Getting Results!

I think all this community contribution to NuGet is a big factor in the success of NuGet. With your help (and a few recent tweaks to their popularity algorithm), we’ve become the #1 most popular extension on the Visual Studio Extension Gallery website.

Visual Studio Gallery - Google

If you enjoy using NuGet and have a moment, consider going to the site and rate NuGet.

Moving Forward

As well as I think NuGet is doing, I’m by no means satisfied. In fact, I’m probably one of the most critical people when it comes to where NuGet is today as compared to where I’d like NuGet to be.

My team is a very small team. If we’re going to make even more progress than we’ve had, we’re going to need to cultivate contributors, both drive-by and consistent. That seems to me like the best way to scale out our development.

If you have tips on how to do that best, do let me know! In the meanwhile, I’ll brainstorm some ideas on how we can encourage more people to participate in the development of NuGet.

nuget, code, open source comments edit

When installing a package into a project, NuGet creates a packages.config file within the project (if it doesn’t already exist) which is an exact record of the packages that are installed in the project. At the same time, a folder for the package is created within the solution level packages folder containing the package and its contents.

Currently, it’s expected that the packages folder is committed to source control. The reason for this is that certain files from the package, such as assemblies, are referenced from their location in the packages folder. The benefit of this approach is that a package that is installed into multiple projects does not create multiple copies of the package nor the assembly. Instead, all of the projects reference the same assembly in one location.

If you commit the entire solution and packages folder into source contral, and another user gets latest from source control, they are in the same state you are in. If you omitted the the packages folder, the project would fail to build because the referenced assembly would be missing.


This approach doesn’t work for everyone. We’ve heard from many folks that they don’t want their packages folder to be checked into their source control.

Fortunately, you can enable this workflow today by following David Ebbo’s approach described in his blog post, Using NuGet without committing Packages.

But in NuGet 1.4 we’re planning to make it integrated into NuGet. We will be adding a new feature to restore any missing packages and the packages folder based on the packages.config file in each project when you attempt to build the project. This ensures that your application will compile even if the packages folder is missing at the time, which might be the case if you don’t commit it to source control.


We have certain requirements we plan to meet with this feature. Primarily, it has to work in a Continuous Integration (CI Server) scenario. So it must work both within Visual Studio when you build, but also outside of Visual Studio when you use msbuild.exe to compile the solution.

For more details, please refer to:

If you have feedback on the design of this feature, please provide it in the discussion thread. Also, do keep in mind that this next release is our first iteration to address this scenario. We think we’ll hit the primary use cases, but we may not get everything. But don’t worry, we’ll continue to release often and address scenarios that we didn’t anticipate.

Thanks for your support!

nuget, code, open source comments edit

In continuing our efforts to release early, release often, I’m happy to announce the release of NuGet 1.3!

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 is available as an update. Click the Upgrade button and you’re all set. It only takes a minute and it really is that easy to upgrade.


As always, there’s a new version of NuGet.exe corresponding with this release as well as a new version of 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


Expect a new version of Package Explorer to be released soon as well. It is a click once application so all you need to do is open it and it will prompt you to upgrade it when an upgrade is available.

There’s a lot of cool improvements and bug fixes in this release as you can see in the release announcement. One of my favorite features is the ability to quicky create a package from a project file (csproj, vbproj) and push the package with debugging symbols to the server. David Ebbo wrote a great blog post about this feature and Scott Hanselman and I demonstrated this feature 20 minutes into our NuGet in Depth talk at Mix 11., mvc, code comments edit

Say you want to apply an action filter to every action except one. How would you go about it? For example, suppose you want to apply an authorization filter to every action except the action that lets the user login. Seems like a pretty good idea, right?

Currently, it takes a bit of work to do this. If you add a filter to the GlobalFilters.Filters collection, it applies to every action, which in the previous scenario would mean you already need to be authorized to login. Now that is security you can trust!


You can also manually add the filter attribute to every controller and/or action method except one. This solution is a potential bug magnet since you would you need to remember to apply this attribute every time you add a new controller. Update: There’s yet another approach you can try which is to write a custom authorize attribute as described in this blog post on Securng your ASP.NET MVC 3 Application.

Fortunately, ASP.NET MVC 3 introduced a new feature called filter providers which allow you to write a class that will be used as a source of action filters. For more details about what filter providers are, I highly recommend reading Brad Wilson’s blog post on filters.

In this case, what I need to write is a conditional action filter. I actually started writing one during my ASP.NET MVC 3 presentation at this past Mix 11 but never actually finished the demo. One of the many mistakes that inspired my blog post on presentation tips.

In this blog post, I’ll finish what I started and walk through an implementation of a conditional filter provider which will let us accomplish applying filters to action methods based on any criteria we can think of.

Here’s the approach I took. First, I wrote a custom filter provider.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web.Mvc;

public class ConditionalFilterProvider : IFilterProvider {
  private readonly 
    IEnumerable<Func<ControllerContext, ActionDescriptor, object>> _conditions;

  public ConditionalFilterProvider(
    IEnumerable<Func<ControllerContext, ActionDescriptor, object>> conditions)
      _conditions = conditions;

  public IEnumerable<Filter> GetFilters(
      ControllerContext controllerContext, 
      ActionDescriptor actionDescriptor) {
    return from condition in _conditions
           select condition(controllerContext, actionDescriptor) into filter
           where filter != null
           select new Filter(filter, FilterScope.Global, null);

The code here is fairly straightforward despite all the angle brackets. We implement the IFilterProvider interface, but only return the filters given that meet the set of criterias represented as a Func. But each Func gets passed two pieces of information, the current ControllerContext and an ActionDescriptor. Through the ActionDescriptor, we can get access to the ControllerDescriptor.

The ActionDescriptor and ControllerDescriptor are abstractions of actions and controllers that don’t assume that the controller is a type and the action is a method. That’s why they were implemented in that way.

So now, to use this provider, I simply need to instantiate it and add it to the global filter provider collection (or register it via my Dependency Injection container like Brad described in his blog post).

Here’s an example of creating a conditional filter provider with two conditions. The first adds an instance of MyFilter to every controller except HomeController. The second adds SomeFilter to any action that starts with “About”. These scenarios are a bit contrived, but I bet you can think of a lot more interesting and powerful uses for this.

IEnumerable<Func<ControllerContext, ActionDescriptor, object>> conditions = 
    new Func<ControllerContext, ActionDescriptor, object>[] { 
    (c, a) => c.Controller.GetType() != typeof(HomeController) ? 
      new MyFilter() : null,
    (c, a) => a.ActionName.StartsWith("About") ? new SomeFilter() : null

var provider = new ConditionalFilterProvider(conditions);

Once we create the filter provider, we add it to the filter provider collection. Again, you can also do this via dependency injection instead of adding it to this static collection.

I’ve posted the conditional filter provider as a package in my personal NuGet repository I use for my own little samples located at Feel free to add that URL as a package source and Install-Package ConditionalFilterProvider in order to get the source.

Tags: aspnetmvc,, filter, filter providers

code, open source comments edit

Eric S. Raymond in the famous essay, The Cathedral and the Bazaar, states,

Release early. Release often. And listen to your customers.

This advice came from Eric’s experience of managing an open source project as well as his observations of how the Linux kernel was developed.

But why? Why release often? Do I really have to listen to my customers? They whine all the time! To question this advice is sacrilege to those who have this philosophy so deeply ingrained. It’s obvious!

Or is it?

When I was asked this in earnest, it took me a moment to answer. It’s one of those aphorisms you know is true, but perhaps you’ve never had to explain it before. It’s hard to answer not because there isn’t a good answer, but because it’s difficult to know where to begin.

It’s healthy to challenge conventional wisdom from time to time to help avoid the cargo cult mentality and remind oneself all the reasons good advice is, well, good advice.

One great approach is to take a step back and imagine explaining this to someone who isn’t ingrained in software development, such as a business or marketing person. Why is releasing early and often a good thing?It helps to clarify that releasing early doesn’t mean waking up at 3:00 AM to release, though that may happen from time to time.

In this blog post, I’ll look into this question as well as a couple of other related questions that came to mind as I thought about this topic:

  • If releasing often is a good thing, why not release even more often?
  • What factors affect how often is often enough?
  • What are common objections to releasing often?
  • Why does answering a question always leave you with more questions?

I’ll try answering these questions as best as I can based on my own experiences and research.

Why is it a good thing?

What are the benefits of releasing early and often? As I thought through this question and looked at the various responses that I received from asking the Twitterista for their opinions, three key themes kept recurring. These themes became the summary of my TL;DR version of the answer:

  1. It’s results in a better product.
  2. It results in happier customers.
  3. It fosters happier developers.

So how does it accomplish these three things? Let’s take a look.

It provides a rapid feedback loop

Steve Smith had this great observation (emphasis mine):

The shorter the feedback loop, the faster value is added. Try driving while only looking at the road every 10 secs, vs. constantly.

Driving like that is a sure formula for receiving a Darwin Award.

Every release is an opportunity to stop theorizing about what customers want and actually put your hypotheses to the test by getting your product in their hands. The results are often surprising. After all, who expected Twitter to be so big?

Matt Mullenweg, the creator of WordPress put it best in his blog post, 1.0 is the loneliest number:

Usage is like oxygen for ideas. You can never fully anticipate how an audience is going to react to something you’ve created until it’s out there. That means every moment you’re working on something without it being in the public it’s actually dying, deprived of the oxygen of the real world.

This has played out time and time again in my experience. This happened recently with NuGet when we released a bug that caused sluggishness in certain TFS scenarios, something very difficult to discover without putting the product in real customers hands to use in real scenarios. Thankfully we didn’t have to wait a year to release a proper fix.

As Miguel De Icaza points out,

Early years of the project, you get to course correct faster, keep up with demand/needs

It’s not just customer demands that require course corrections. At times, changing market conditions and other external factors may require you to quickly adjust your planned feature sets and come out with a release in response to these changes. Having short iterations allow more agility to respond to such events keeping your product relevant.

It gets features and bug fixes in customers hands faster

This point is closely related to the last point, but worth calling out. In the Chromium blog, the open source project that makes up the core of the Google Chrome browser, they point out the following in their blog post, also titled Release Early, Release Often (emphasis mine):

The first goal is fairly straightforward, given our pace of development. We have new features coming out all the time and do not want users to have to wait months before they can use them. While pace is important to us, we are all committed to maintaining high quality releases — if a feature is not ready, it will not ship in a stable release.

Well why not make users wait a few months? As Nate Kohari points out,

Nothing is real until it’s providing value (or not) to your users. Having completed work that isn’t released is wasteful.

The longer a feature is implemented, but not being used in real scenarios, the more the context for the feature is lost. By the time it’s in customers hands, the original reason for the feature may be lost in the smoky mists of memory. And as feedback on the feature comes in, it takes time for the team to re-acquaint itself with the code and the reasons the code was written the way it was. All of that ramp up time is wasteful.

Likewise, the faster the cycle, the shorter the time the team has to live with a known bug out there in the product. Sometimes products ship with bugs that aren’t serious enough for an emergency patch, but annoying enough that customers are unhappy with having to live with the bug till the next release. This also makes developers unhappy as well as they are the ones who hear about it from the customers. A short release cycle means nobody has to live with these sort of bugs for long.

It reduces pressure on the development team to “make” a release

This point is also taken from the Chromium blog post as well. You can probably tell that post really resonated with me.

As a project gets closer and closer to the end of the release cycle, the team starts to make hard decisions regarding which bugs or features will get implemented or get punted. The pressure builds as the team realizes, if they don’t get the fix in this release, customers will have to wait a long time to get it in the next. As the Chromium blog post states:

Under the old model, when we faced a deadline with an incomplete feature, we had three options, all undesirable: (1) Engineers had to rush or work overtime to complete the feature by the deadline, (2) We delayed the release to complete that feature (which affected other un-related features), or (3) The feature was disabled and had to wait approximately 3 months for the next release. With the new schedule, if a given feature is not complete, it will simply ride on the the next release train when it’s ready. Since those trains come quickly and regularly (every six weeks), there is less stress.

The importance of this point can’t be overstated. Releasing often is not only good for the customers, it’s good for the development team.

It makes the developers excited!

This point was one of the original observations that Eric Raymond made in his essay,

So, if rapid releases and leveraging the Internet medium to the hilt were not accidents but integral parts of Linus’s engineering-genius insight into the minimum-effort path, what was he maximizing? What was he cranking out of the machinery?

Put that way, the question answers itself. Linus was keeping his hacker/users constantly stimulated and rewarded – stimulated by the prospect of having an ego-satisfying piece of the action, rewarded by the sight of constant (evendaily) improvement in their work.

Contrary to popular depictions, developers love people! And we especially love happy people, which makes us very excited to see features and bug fixes get into the customers hands because it makes them happy.

It’s demoralizing to implement a great feature or key bug fix and then watch it sit and stagnate with nobody using it.

This is especially important when you’re trying to harness the energy of a community of open source contributors within your project. It’s important to keep their attention and interest in the project high, or you will lose them. And nothing makes contributors more excited than seeing their hard work be released into the public for the world to use and recognize.

Yes, appeal to your contributors egos! Let them share in the glory now, and not months from now! Let them receive the recognition they deserve sooner rather than later!

It makes the schedule more predictable and easier to scope

Quick! Tell me how many piano tuners there are in Chicago? At first glance, this is a very difficult task. But if you break it down into smaller pieces, you can come up with a pretty good estimate for each small piece which leads to a decent overall estimate.

This type of problem is known as a Fermi problem named after the physicist Enrico Fermi who was renown for his estimation abilities. The story goes that he estimated the strength of an atomic bomb by measuring the distance pieces of paper travelled that he ripped up and dropped from his hands.

Breaking down a long product schedule into short iterations is similar to attacking a Fermi Problem. It’s much easier to scope and estimate a short iteration than it is a large one.

Again, going back to the Chromium blog post,

The second goal is about implementing good project management practice. Predictable fixed duration development periods allow us to determine how much work we can do in a fixed amount of time, and makes schedule communication simple. We basically wanted to operate more like trains leaving Grand Central Station (regularly scheduled and always on time), and less like taxis leaving the Bronx (ad hoc and unpredictable).

Keeps your users excited and happy

Ultimately, all the previous points I made lead to happy customers. When a customer reports a bug, and a fix comes out soon afterwards, the customer is happy. When a customer sees new features continually released that make their lives better, they are happy. When your product does what they want because of the tight feedback cycle, the customers are ultimately much happier with the product.

And this doesn’t just benefit your current customers. Potential new customers will be attracted to the buzz that frequent releases generate. As Atley Hunter points out,

Offering software consistently and frequently helps to foster both market buzz and continued interested from your installbase.

Continual releases are the sign of an active and vibrant product and product community. This is great for marketing your product to new audiences.

So Why Not Release All The Time?

If releasing often is such a good thing, why not release all the time? Isn’t releasing more often better than less often?

Releasing every second of the day time might not be possible since it does take time to implement features, but it’s not unheard of to release features as soon as they are done. This is the idea behind a technique called continuous deployment, which is particularly well suited to web sites.

When I worked at Koders (now part of BlackDuck software), we pushed a release every two weeks. We wanted to move towards a weekly release, but it took a couple of days to build our source code index. Our plan was to make the index build incrementally so we could deploy features more often and hopefully reach the ultimate goal of releasing as soon as a feature was completely done.

I think this is a great idea, but not always attainable without significant changes in how a product is developed. For example, with NuGet, we have a continuous integration server, that produces a build with every check-in. In a manner of speaking, we do have continuous deployment because anyone can go and try out these builds.

But I wouldn’t apply the “continuous deployment” label to what we do because we these CI builds are not release quality. To get to that point would require changing our development process so that every check-in to our main branch represented a completely end-to-end tested feature that we’re ready to ship.

At this point, I’m not even sure that continuous deployment is right for every product, though I’m still learning and open to new and better ideas. To understand why I feel this way, let me transition to my next question.

What factors affect how often is often enough?

I think there are several key factors that determine how often a product should be released.

Adoption Cost to the Customers

Some products have a higher adoption cost when a new release is produced. For example, websites have a very low adoption cost. When produces a release daily or even more than once a day, the cost to me is very little as long as the changes aren’t too drastic.

I simply visit the site and if I notice the new feature, I start taking advantage of it.

A product like Google Chrome has a slightly higher adoption cost, but not much. I’m unlikely to have critical infrastructure completely dependent on their browser. The browser updates itself and I simply take advantage of the new features.

But a product like a web framework has a much higher adoption cost. There’s a steeper learning curve for a new release of a programming framework than there is for a browser update. Also, authors will want time to be able to write their training materials, courses, books before they become obsolete by the next version.

And folks running sites on these framework versions want time to upgrade to the next version without having that version become obsolete immediately. Major releases of frameworks allow the entire ecosystem to congeal around these major release points. Imagine if ASP.NET MVC had 24 official releases in two years. How much harder would it be to hire developers to support your ASP.NET MVC v18 application when they want to be on the latest and greatest because we all know v24 is the cats pajamas.

I believe this is why you see Ruby on Rails releasing every two years and ASP.NET MVC release yearly. Note that both of these products still release previews early and often, but the final “blessed” builds come out relatively infrequently.

Maturity of the product

The other factor that might affect release cadence is the maturity of the product. When a product is playing catch-up, it has to release more often or risk falling further and further behind.

As a product matures, all the low-hanging fruit gets taken and sometimes a longer release cycle is necessary as they tackle deeper features which require heavier investments of time. Keep in mind, this is me theorizing here. I don’t have hard numbers to base this on, but it’s based on my observations.

Customer Costs

Sometimes, the customers tolerance for change affects release cadence. For example, I don’t think customers would tolerate a new iPhone hardware device every month because they’ll constantly feel left behind. A year is enough time for many (but not all) consumers to feel ready to upgrade to the next version.

Deployment Costs

One last consideration might be the costs to deploy the product. For hardware, this can be a big factor when the design of the product changes drastically from one version to the next.

Suddenly new supply chains may need to be set in place. Factories may need to be retrofitted to support the new or changing components. The products have to physically be shipped to the stores.

All these things can affect how often a new product can be shipped.

Common objections to Releasing Often

I think there are three main objections to this model I’ve heard or can think of. The first is that it forces end users to update their software more often. I’ve addressed this point already by looking at customer adoption as a gating factor in how often the product should be released. Many products can be updated quietly without requiring users to take any action. If the new features are designed well, customers will naturally discover them and learn them without too much fuss. In this model, avoid having these regular releases move everyone’s cheese by re-arranging the UI and that sort of thing.

Another concern raised is that this leads to more frequent lower quality releases rather than less frequent releases with higher polish and quality. After all, releases always contain overhead and by having more releases, you’re multiplying this overhead over multiple releases.

This is definitely a concern, but one that’s easily mitigated. Before we address that, but as my co-worker Drew Miller points out, long release cycles mask wasteand that waste is far greater than the cost of more frequest release overhead.

  • The more often you release, the better you are at releasing; release overhead decreases over time. With long release cycles, the pain of release inefficiency is easy to ignore and justify and the urgency and incentive to trim that waste is very low.
  • The sense of urgency for frequent releases drives velocity, more than off-setting the cost of release overhead.
  • The rapid feedback with frequent releases reduces the waste we always have for course correction within a long release cycle. A great example of this is the introduction of ActionResult to ASP.NET MVC 1.0 between Preview 2 and 3. That was costly, but would’ve been more costly if we had made that change much later.
  • The slow start of a long release cycle alone is usually more wasteful than the total cost of release overhead over the same period.
  • Long release cycles may have milestone overhead that can be as great (or greater) than release overhead.

Release as Often as Possible and Prudent

There’s probably a lot more that can be written on this topic, but I’m quickly approaching the TL;DR event horizon (if I haven’t passed it already). I’m excited to continue to learn more about effective release strategies so I look forward to your thoughtful comments on this topic.

At the end, my goal was to make it clear why releasing early and often is a good thing. I don’t currently believe there’s an empirical answer to the question, how often should you release? Rather, my answer right now is to suggest as often as possible and prudent.

If you release often, but find that your releases tend to be of a low quality, then perhaps it’s time to take the dial back a bit. If your releases are of a very high quality, perhaps it’s worth looking at any waste that goes into each release and trying to eliminate it so you can release even more often if doing so would appeal to your customers.

For more reading, I recommend:

code, open source, nuget comments edit

The Magic 8-ball toy is a toy usually good for maybe one or two laughs before it quickly gets boring. Even so, some have been known to make all their important life/strategic decisions using it, or an equivalent mechanism.

The way the toy works is you ask it a question, shake it, and the answer to your question appears in a little viewport. What you’re seeing is one side of an icosahedron (20-sided polyhedron, or for you D&D folks, a d20). On each face of the d20 is a potential answer to your yes or no question.


I thought it would be fun to write a NuGet package that emulates this toy as one of my demos for the NuGet talk at Mix11. Yes, I am odd when it comes to defining what I think is fun. When you install the package, it adds a new command to the Package Manager Console.

The command I wrote didn’t have twenty possible answers, because I was lazy, but it followed the same general format. This command also includes support for tab expansions, which feel a lot like Intellisense.

The following screenshot shows an example of this new command, Get-Answer, in use. Note that when you hit tab after typing the command, you can see a tab expansion suggesting a set of questions. It’s important to note that unlike Intellisense, you are free to ignore the tab expansion here and type in any question you want.


In this blog post, I will walk through how I wrote and packaged that command. I must warn you, I’m no PowerShell expert. I wrote this as a learning experience with the help of other PS experts.

The first thing to do is write an init.ps1 file. As described in the NuGet documentation for creating a package on CodePlex:

Init.ps1 runs the first time a package is installed in a solution. If the same package is installed into additional projects in the solution, the script is not run during those installations. The script also runs every time the solution is opened. For example, if you install a package, close Visual Studio, and then start Visual Studio and open the solution, the Init.ps1script runs again.

This script is useful for packages that need to add commands to the console because they’ll run each time the solution is opened. Here’s what my init.ps1 file looks like:

param($installPath, $toolsPath, $package)

Import-Module (Join-Path $toolsPath MagicEightBall.psm1)

The first line declares the set of parameters to the script. These are the parameters that NuGet will pass into the init.ps1 script (note that install.ps1, a different script that can be included in NuGet packages, receives a fourth $project parameter).

  • $installPath is the path to your package install
  • $toolsPath is the path to the tools directory under the package
  • $package is a reference to your package

The second line of the script is used to import a PowerShell module. In this case, we specify a script named MagicEightBall.psm1 by its full path. We could write the entire script here in init.ps1, but I’ve been told it’s good form to simply write scripts as modules and then import them via init.ps1and I have no reason to not believe my source. I suppose init.ps1 could also import multiple modules rather than one.

Let’s look at the code for MagicEightBall.psm1. It’s pretty brief!

$answers =  "As I see it, yes", 
            "Reply hazy, try again", 
            "Outlook not so good"

function Get-Answer($question) {
    $answers | Get-Random

Register-TabExpansion 'Get-Answer' @{
    'question' = { 
        "Is this my lucky day?",
        "Will it rain tonight?",
        "Do I watch too much TV?"

Export-ModuleMember Get-Answer

The first line of code simply declares an array of answers. The real Magic Eight Ball has 20 in all, so feel free to add them all there.

I then define a function named Get-Answer. The implementation demonstrates one of the cool things I like about Powershell. I can simply pipe it into the Get-Random method and it returns a random answer from the array.

Skipping to the end, the last line of code calls Export-Module on this function, which makes it available in the Package Manager Console.

So what about that middle bit of code that calls Register-TabExpansion? Glad you asked. That function provides the Intellisense-like behavior for our function by registering a tab expansion.

It takes two parameters, the first is the name of the function, in this case Get-Answer. The second is a dictionary where the keys are the names of the parameters of the function, and the values contain an array of expansion options for that function. Since are function only has one parameter named question, we add 'question' as the key to the dictionary and supply an array of potential questions as the value.

With these two files in place, I simply opened up Package Explorer and selected File > New from the menu to start a new package and dragged both of the script files into the Package contentswindow. NuGet recognized the files as being PowerShell scripts and offered to put them in the Tools folder.

I then selected Edit > Edit Package Metadata from the menu to enter the NuSpec metadata for the package and clicked OK at the bottom.


With all that done, I selected the File > Save As… menu to save the package on disk so I could test it out. Once I was done testing, I selected File > Publish to publish the package to the real NuGet feed.

It’s really that simple to write a package that adds a command to the Package Manager console complete with tab expansions.

In a future blog post, I’ll write about how I wrote MoodSwings, a package that can automate Visual Studio from within the Package Manager Console. If you have the NuGet Package Manager Console open, you can try out this package by running the command:

Install-Package MagicEightBall