Hello ASP.NET 5 World – Part I

First of all, Visual Studio 2015 CTP 6 was released this week and with it the beta 3 of CoreCLR and ASP.NET 5. I’ll be using beta 3 for this post. If you’re not installing VS, make sure you re-install KVM, because there were a few changes (different layout on the file system, new commands on KPM, etc.).

Programming model

In my previous post I wasn’t clear about one thing: ASP.NET’s 5 side-by-side deployment, pay-for-play and multi-host approach also means that the monolithic System.Web is gone. No more IHttpHandler, IHtpModule and co. Of course many of the features on System.Web will have its counterpart on ASP.NET 5 stack.

ASP.NET 5 is OWINish. In fact, the Katana project was integrated into ASP.NET 5, defining the base programming model. This means we’ll deal with middlewares, AppFunc and the enviroment dictionary. Well, actually the ASP.NET 5 HTTP object model has a higher abstraction level rather than exposing the raw OWIN concepts.That’s why I said it is “OWINish”.

Hello World!

So, what does it take to have a simple “Hello World” in ASP.NET 5? It’s actually quite simple. I found this nice tutorial with all the steps to set up from the ground, so I won’t reproduce them here. Just note that the post is based on beta 2 and I’ll be using beta 3.

The bare minimum is to define: a Startup class, where you configure your application. In this case, I’m configuring it to say hello as a response to all the requests.

using System;
using Microsoft.AspNet.Builder;
using Microsoft.AspNet.Http;

namespace HelloWorld.Web
{
public class Startup
{
public void Configure(IApplicationBuilder app)
{
app.Run(ctx => ctx.Response.WriteAsync("Hello ASP.NET 5 world! Time: " + DateTime.Now));
}
}
}

And a project.json file with the application dependencies. In this case I’m also configuring a command to be able to run the application from the command line, since I’ll be using a self-host.

{
"dependencies": {
"Microsoft.AspNet.Hosting": "1.0.0-beta3",
"Microsoft.AspNet.Server.WebListener": "1.0.0-beta3"
},
"commands": {
"web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls http://localhost:5000"
}
}

The bootstrap is convention-based: ASP.NET searches the main assembly of the application for a class named Startup and then for a method named Configure that has the signature above. The app.Run method is used to register code that kicks in when no other component handles the request. Since I have nothing else, it will run for every request. This is somewhat similar to an IHttpHandler on previous versions.

The web command is an easy way to configure the self-hosted server and then start it using k on the command line. So, if you put the two files above on a folder, you can restore dependencies and run the application from the command line by doing:

kpm restore
k web

You should see a “Started” message on the console and then you can access the application on http://localhost:5000. And that’s it!

On the following post I’ll add a few more bits on this example, namely registering a middleware and hosting on IIS express, as well as looking a bit more into the HTTP abstractions and comparing them to the ones previously found on Katana project.

Advertisements

Finding my way on the ASP.NET vNext world

As I started digging on .ASP.NET vNext I quickly realized there is a LOT of information to catch up with. NET Core and ASP.NET 5 really are a shift on .NET development, with differences on things such as application frameworks (unification), expressing and resolving dependencies, builds/compilation and deployment. In addition, the new stuff is open sourced on GitHub and, at first, it is not easy to make all the pieces in the puzzle fit together.

One of the first things I noticed was that the letter “K” was everywhere. It’s worth pointing out that K is the code name for ASP.NET vNext and related components.

Getting started

An important part on building the puzzle it to compare the vNext approach with the “old” approach. I found the ASP.NET Panel discussion on Visual Studio Connect event very nice for an overview, namely this comparison screen:

netcorecomparison

NuGet all the way

First, everything is now distributed via NuGet, from community libraries, to the platform libraries themselves! Also, NuGet packages are now the unit of reference within a project (not assemblies).

.NET Core

The most important thing to notice is that there’s a new “version” of .NET around. .NET Core. It is a smaller, cloud/server oriented version of .NET, which is largely based on the same codebase as the “desktop” .NET. .NET Core encompasses two major components:

  • .NET Core CLR – a small runtime capable of side by side deployment (finally!). It includes the same GC and next gen JIT as the full featured .NET, but it doesn’t include, for instance, AppDomains or Code Access Security.
  • .NET Core Libraries – roughly the same code as the .NET BCL, but refactored so that it can be shipped as smaller libraries, via NuGet packages (e.g. System.Collections).

The idea here is that you include the packages you need on a pay-for-play logic (the Core CLR itself will be a NuGet package). This allows you to only get the libraries you need and allows Microsoft to have different (probably smaller) release cycles on the different components.

KRuntime

Related to side-by-side deployment, another big difference is on the application host and runtime loader layers. Currently we have System.Web (all the pipeline stuff) integrated on IIS which loads and hosts the CLR. In vNext, KRuntime is introduced:

The KRuntime is an SDK containing all of the bits needed to build and run an application

KRuntime is cross platform and includes native hosts for the different versions of the CLR (Core, .NET, Mono). It also includes command line tools, namely:

  • KVM – the version manager for KRuntime. It allows you to install and manage the different versions of KRuntime. I find some similarities with the Ubuntu Snappy approach.
  • KPM –  the package manager (node style). It allows you to do things related to using packages or packaging your applications.

Also included in KRuntime somewhere is the application host (layer 3). This is where I’m still a bit confused. The KRuntime repo is under ASP.NET, but I think it probably is more broad. I think it is currently being used for ASP.NET vNext application and the application host for ASP.NET looks for the corresponding entry point (the new Startup class and its Configure method, as far as I can tell). However, the description of the KRuntime structure seems agnostic, which makes me think it really is more generic. In addition, on the dev branch, KRuntime was renamed to .NET Cross Platform Runtime SDK (.NET XRE), which further indicates it shouldn’t apply only to ASP.NET. Makes sense: it should be the new SDK to build, bootstrap and run .NET vNext in general.

EDIT (10/3/2015): .NET XRE was renamed again on the dev branch and now is .NET Execution Environment (DNX). In addition, the target frameworks nomenclature was also changed, which adds up on the idea that KRE (ooops, DNX) is not specific to ASP.NET 5. Also, KVM is now DNVM (.NET Version Manager).

Build

Another difference comes on compilation, as everything is now based on Roslyn. Dependencies can by compiled on-the-fly without outputing assemblies to disk. The same compiler infrastructure is used for design time and runtime (e.g. no more <compilation> section to configure the compilation of MVC Views).

Project files

No more csproj and Visual Studio/msbuil- only stuff. On KRuntime, projects are defined using a JSON file that contains metadata, dependencies, commands and so on. A very nice difference about dependencies is that:

The project.json file only includes NuGet packages that you directly added to your project. If you add a NuGet package that is dependent on other packages, those secondary dependencies are loaded but not listed in the project.json file.

No more entries on “packages.config” just because a direct dependency needs this other package!

Conclusion

ASP.NET 5 is not only about a renewed ASP.NET but also a whole new approach to .NET development. This post didn’t actually go into ASP.NET 5 because I thought it was important to understand a bit more of the new ecosystem first. I’ll leave ASP.NET and more discoveries on XRE and .NET Core for future posts.

Meanwhile, the getting started guide on ASP.NET home on GitHub can put you up and running a XRE/Core CLR sample in minutes. Only from command line! In addition, this post from David Fowler is a good overview of ASP.NET vNext architecture.

Hypermedia on Web APIs

Darrel Miller recently posted a very interesting overview of the state of the art around hypermedia on Web APIs.

Looking around known public APIs – and, of course, the ones I end up developing – it’s easy to agree that many times we’re using generic media-types with additional, out-of-band, semantics. We really should leverage “horizontal” media types for cross-cutting concerns and link relations for additional semantics. This leads me to also agree that there really isn’t a simple answer to Darrel’s question “What should I use”.

Worth reading!