In previous versions of MVC framework, running on top of the “classic” ASP.NET runtime, it was quite common for developers to switch view compilation on, so that the views get compiled upfront, allowing you to see any errors at compile time, rather than at runtime.

This was done by a simply adding true to your csproj file.

Given that everything changes in the new ASP.NET 5 world, how would you do it now? Let’s explore.

One of the key concepts in HTTP API development is the notion of content negotiation (conneg). ASP.NET Web API provided first class support for content negotiation through the use of MediaTypeFormatters.

While MVC 6 is a de facto brand new framework, rebuilt from scratch, the majority of concepts from MVC 5 and Web API 2 have naturally been brought forward, and conneg done through formatters are one of them.

Let’s have a look at formatters in MVC6.

Moments ago, at VS Connect event, Microsoft, through the Corporate Vice President of the Developer Division S. Somasegar, dropped a bomb on the developer community by announcing that the .NET Core Framework, a new true cross platform .NET, has been open sourced (note, it’s still partial, not everything is there yet), and released under a very permissive MIT license. You can read up more on the .NET Core at the official blog.

This is a dramatic shift in an ecosystem that has traditionally been (fair or not) characterized as closed, often unfriendly to developers, Windows-specific (Mono is not, after all, a Microsoft project) and characterized by relatively high entry barriers (Visual Studio, lockdown to Windows Server etc).

I have a bunch of quick thoughts around this that I’d like to share.

One of the cool things about ASP.NET vNext is that it introudces a configuration abstraction, Microsoft.Framework.ConfigurationModel over your application’s configuration.

This is going to replace the old school, limiting approach of forcing you to work with XML configuration only through the System.Configuration classes.

Louis DeJardin has blogged about the ideas behind the isolation of Configuration in his blog post. In the meantime, let’s have a look at how we could enable a ConfigR-based configuration too.

Some time ago I blogged about building next generation Visual Studio support tools with Roslyn. This was when Roslyn was still on its 2012 CTP. A lot has changed since then, with Roslyn going open source, and new iterations of the CTPs getting released.

Most of the APIs used in the original have changed, so I thought it would be a good idea to do a new post, and rebuilt the sample used in the old post from scratch, using the latest Roslyn CTP.

In ASP.NET Web API, if the incoming does not match any route, the framework is simply hard wired to return 404 to the client (or possibly pass through to the next configured middleware, in case of an OWIN hosted Web API). This is done immediately, without entering anywhere further down the pipeline (i.e. message handlers would not be invoked).

However, an interesting question was posted recently at StackOverflow - what if you want to override that hard 404, and given your specific routing requirements, respond to the client with a different status code if a specific route condition fails?

I already answered at StackOverflow, but decided this deserves a blog post regardless.

As you might now by now, last month my ASP.NET Web API 2 Recipes book was released by Apress. The book contains over 100 recipes covering various Web API scenarios that aim to help you save some headaches when working on your current or next Web API project.

Each of the recipes has got an accompanying Visual Studio solution, which illustrates the given problem and presents a solution in a simple, isolated manner.

Obviously, it would be great if you went ahead and bought a book (then you would get an in-depth analysis of each case), but the source code itself is available for free at Github and as a download from Apress.

I hope it becomes a useful collection, illustrating how to deal with various Web API problems/scenarios.

Please note that some of the early examples might appear simple or even trivial - that’s the case with introductory recipes, where the gist of the matter is discussed in the book itself.

I have seen in some StackOverflow questions that the examples on Github have already helped a couple of folks, which is fantastic. You can find a summary of the samples below - they are structured in the book and in the repository the same way.

When you are developing an ASP.NET Web API application, you can chose whether you want to return a POCO from your action, which can be any type that will then be serialized, an instance of HttpResponseMessage, or, since Web API 2, an instance of IHttpActionResult.

Let’s have a look at what really happens under the hood afterwards, and discuss some of the things about the response pipeline that you might have not known before.

ASP.NET Web API provides an IUrlHelper interface and the corresponding UrlHelper class as a general, built-in mechanism you can use to generate links to your Web API routes. In fact, it’s similar in ASP.NET MVC, so this pattern has been familiar to most devs for a while.

The main problem of it is that it’s based on magic strings, as, to generate a link, the route name has to be passed as a string literal. Moreover, all the parameters that are required to built up the link, are simply a set of name-values, represented by a dictionary or an anonymous object, which is hardly optimal. Code is not coherent, refactoring becomes a pain and in general error potential is high.

My friend, and one of the most respected folks in the Web API community, Pedro Felix, has created a library called Drum, designed to avoid the pitfalls of the UrlHelper, allowing you to build links for Web API direct routing (introudced in Web API 2) in a strongly typed way.

Drum works with any direct routing provider, including my own Strathweb.TypedRouting.

My long promised book, ASP.NET Web API 2: Recipes has been published by Apress last week. I announced the book a while ago, when I also tried to explain the general idea behind the book. I nshort, I really wanted to write a no-nonsense, blog-like, problem-solution book for Web API. Since then, as you may have noticed, the title got changed to reflect the latest iteration of Web API. The majority of recipes are compatible with both v1 and v2 of the framework, however some recipes are obviously Web API 2 only (i.