Getting the ASP.NET 5 samples to work on Windows with the “new” dnvm (and beta 5)

[UPDATE] If you clone the dev branch’s samples instead of the master branch, it should be easier. You will still need to update the Startup.cs file for now though. Pull-request made… (That was a long blog post to no use…still gives some insight into how it works though…) [END UPDATE]

[UPDATE 2] Now updated to beta-5 if anyone still wants it considering the update above… [END UPDATE 2]

Yesterday I finally had time to sit down and play with the new ASP.NET 5 runtime, which is something I have wanted to do for quite some time. However, it kind of annoyed me that I couldn’t just install the ASP.NET 5 runtime, clone the samples from GitHub and get started, as it generated a whole heap of errors. After an hour or so of Googling and trying things out, I finally got it working, so I thought I would write down what I did to get it to work.

Note: This codebase is moving ridiculously fast, so this post is going to be old within a very short while. Everything is based on the code as of today, March 20th 2015.

The first step is to to install the ASP.NET 5 version manager on your machine. This is done by going to the ASP.NET GitHub repo and getting the PowerShell command needed.

A bit down on the home page, you will see a section called “Install the .NET Version Manager (DNVM)”. Under this, it mentions that it was formerly known as kvm… Kvm is still the, as they call it, “stable-ish” version, but the cool stuff is handled with the dnvm, which is called “optimistic”.

The thing we are looking for is the PowerShell script that looks like this

@powershell -NoProfile -ExecutionPolicy unrestricted -Command "&{$Branch='dev';iex ((new-object net.webclient).DownloadString(''))}"

To install the .NET Version Manager, paste that string into a console window and press enter. This will generate a screen similar to this


Now, the dnvm is installed on your machine. To be honest, it is simply a PowerShell script and a cmd file located at %USERPROFILE%\.dnx. This path, or to be honest one that goes to %USERPROFILE%\.dnx\bin, is added to the PATH environment variable to make it accessible in the console.

Next, we need to install an actual runtime environment. This is easily done by running the command

dnvm upgrade

This will generate some nicely colored ASCII goodness running, and at the end of it, it will tell you that it has installed version XXX at some location on your machine. In my case, it installed version Wait…what!? beta-4? I want beta-5!

Beta-4 is what you get from the “stable”/master branch on GitHub. However, dnvm now supports getting stuff from the “unstable”/dev branch as well. All you need to do is to append –u or –unstable

dnvm upgrade –u

Now it installed what I needed, the 1.0.0-beta5-11682.

Now you have one runtime installed. In my case, the full CLR beta5 (and 4) version(s). If you want to install the CoreCLR version, you can just run the upgrade command again, but add the switch –Runtime CoreCLR

dnvm upgrade –u –runtime CoreCLR

Note: When installing the CoreCLR version, it will also pre-compile the code to native images to make it faster to startup. So it takes a little bit longer to do…

If you want to see what versions you have installed, you can run the list command

dnvm list

In my case, that generates a list that looks like this at the moment


As you can see, the CoreCLR is set as the active version. This is because I installed that last. If I want to switch to the full CLR, I just run

dnvm use 1.0.0-beta5-11682 -r CLR

Yes, it is really that easy to switch between versions of the runtime… Try doing that in the current .NET world…

Ok, now that we have the runtime installed, let’s go ahead and get the samples from GitHub. They are in the same repo as the dnvm stuff that we used before, so all we need to do is to get the “clone URL” from that page, and clone the repo to a local folder on our machine. Like this

git clone

Once we have the cloned repo, we can aim our command line at the sample we want to run. In my case, that would be the HelloMvc sample, which is located at “Home/samples/latest/HelloMvc”.

Next we need to restore the required packages. This is done using the tool called dnu.exe and the command restore

dnu restore

This will print out a whole heap of data on the screen explaining what it is doing. The short version being that it is downloading all the NuGet packages needed to run the application.

The samples in the /latest/ folder have a very simple definition of the versions for the packages needed. They are defined as 1.0.0-*, which will get the latest version available. At the time of writing that would be beta-5…

The new runtime is built around a much more modular framework, downloaded from NuGet. This way, we can get a much more lean deployment, and easier upgrades.

Once this is done, GitHub tells us that all we need to do is run the sample by running

dnx . web

Unfortunately, that results in an error like this


Yeah, a big fat System.InvalidOperationException with the message “Failed to resolve the following dependencies for target framework 'DNX,Version=v4.5.1'” and so on…

Ok, so that’s where the GitHub instructions fail, and you start scratching your head as to why.

Well, first of all, the project.json file for the samples is based on and “old” naming of the environments. That means that we have to update it to the new.

The old file includes a “frameworks” fragment that says

    "frameworks": {
        "aspnet50": {},
        "aspnetcore50": {}

Unfortunately, that is, as said before, the old naming standard. The new one is dnxXXX, not aspnet. So it needs to be changed to

"frameworks": {
        "dnx451": {},
        "dnxcore50": {}

And while in the project.json, it is pretty obvious that all dependencies are based on the XXX-beta3 versions. So let’s update that to the latest. And why not make it the REALLY latest at all times. Let’s just change the dependencies to 1.0.0-*. Except for Mvc, which is 6.0.0-*

Now that we have fixed that, we can try running “dnx . web” again.

Oops, same error! However, this time we have changed the project.json to use “another” framework. So let’s try running “dnu restore” again as suggested in the error message. And once again, it runs through and prints our a whole heap of information about what it is fetching from NuGet.

dnu restore

Ok, that just tells me that it can’t find the beta-5 packages… What’s up with that? Well, the beta-5 packages are on another NuGet feed, or rather MyGet feed. To get access to them, you need to add that feed to the available NuGet feeds.

If you open the Visual Studio 2015 Preview and go to “Tools > Options…” and then open the node “NuGet Package Manager > Package Sources”, you will get something like this


Add a new source by pressing the huge plus sign. Then enter some useful name together with the source “”, and then press “Update” to persist it


I’m not 100% sure about what feeds are used, but I have the following active (in the following order)

And that seems to work…

Close the Options window, return to the command line and run “dnu restore”…again... This time it should just run through without any errors.

Ok, let’s try it again, “dnx . web”. And OH NOES! it failed again…


But this time it is another exception.

This time it says “System.IO.FileLoadException: Could not load file or assembly 'HelloMvc' or one of its dependencies”. Ok, that doesn’t seem right… And if you keep on reading, it says “error CS1061: ‘IApplicationBuilder' does not contain a definition for 'UseServices' and no extension method 'UseServices' accepting a first argument of type 'IApplicationBuilder' could be found (are you missing a using directive or an assembly reference?)”. Hmm…that sounds really wrong…

That is because we don’t register services using the UseServices() extension method anymore, so that extension method doesn’t exist anymore. Instead, we use a method called ConfigureServices(). So we need to modify the startup.cs file and remove the call to UseServices() and add a method called ConfigureServices(). Like this

namespace HelloMvc
public class Startup
public void ConfigureServices(IServiceCollection services)

public void Configure(IApplicationBuilder app)





Ok, let’s try again. “dnx . web”… image

And there it is, a running sample. And if you open your browser and navigate to http://localhost:5001/ you will see something like this


Success! We finally have the HelloMvc sample up and running!

However, it is still running on the full CLR. What if we want to switch to the Core CLR? Well, just run “dnvm use 1.0.0-beta5-XXX –r CoreCLR”, depending on your version, to switch to the CoreCLR. Then run “dnx . web” to start the server, and you should be good to go. If you get any errors, run “dnu restore” to make sure you go the right dependencies for the CoreCLR

That’s it! Yes, there are a few steps to get it to work, but at least it works now! Or should I say “works for now”…this could change at any moment to be honest. But hopefully this will get you going with the samples.

Comments (6) -

Thanks man! I was getting some trouble to make dnx available globally. This helped a lot!

Thanks for the great post, this info is hard to find.

greetings Damien

Good post! BTW, with the framework RC, you no longer need (nor can use) the . after dnx.

Your fixes are in latest AspNet samples. Hurrah! Alas, now there are new, fresh errors:
- error CS0234: The type or namespace name 'DependencyInjection' does not exist in the namespace 'Microsoft.Framework'
- error CS0246: The type or namespace name 'IServiceCollection' could not be found

Yeah, this is a pretty old post. There are a bunch of things that have changed, and there are more stuff that will change. I didn't think people even looked at this post considering that it is for beta 5... Smile

Well, it's not so old that it describes now-obsolete kvm/klr/kre! Smile It's still a useful walkthrough on installation and use of dnvm/dnu/dnx. So, kudos!

I'm just surprised after all this time it's still so hard to get aspnet to run. I finally got aspnet beta8 running on coreclr beta8, but (to my surprise) only running kestrel. "dnx web" had errors as above.

In the process, it seemed to me that it's not actually a good idea to specify dependencies as "1.0.0-*", because you don't know what versions of each library you're going to get and therefore how compatible they will be with your project and each other. At least, not right now while everything is in flux. Hopefully as the CoreCLR libraries stabilize, they'll follow SemVer compatibility conventions better.

It's really awesome information.

Add comment