A while ago I wrote a post about formatters in MVC 6.

Since then, there have been some changes regarding XML handling and an interesting feature that was added recently that was not part of that post, so I think it warranties a follow up. XML formatter is now removed by default. On top of that, MVC 6 will attempt to sniff out whether your request is originating from a browser’s address bar and adjust content negotiation accordingly.

In the past I did a couple of blog posts (here and here) about how ASP.NET Web API discovers controllers.

ASP.NET MVC 6 supports both regular controllers (inheriting from Controller base type) and POCO controllers. Let’s have a look at how the discovery of them happens in ASP.NET MVC 6. Note that the code and mechanisms discussed in this article were introduced after ASP.NET 5 beta3 was released, so it is not yet available if you use the version of ASP.NET 5 bundled with Visual Studio 2015 CTP6.

This is something I hacked together last night, but it was a very interesting exercise into customizing the new (or rather, future) ASP.NET MVC 6 to suit your needs.

If you visit this blog from time to time, some time ago I blogged about building strongly typed routing provider for ASP.NET Web API (code is here). That was built around extensibility points provided by the direct routing mechanism (better known as direct routing’s default implementation - attribute routing).

So I thought, it would be fun to port this solution to MVC 6. However, while MVC 6 supports attribute routing, it does not provide the same abstractions over the routing mechanism. Instead it exposes something new for both MVC and Web API developers - IApplicationModelConvention, which is what we’ll use here.

There are many posts out there, including on this blog, about what’s in ASP.NET MVC 6 and how to use it. This one however, will be about what’s not in the framework, or at least not in the same way as you might be used to it from MVC 5/Web API 2 - the ability to override filters. I was recently working on an MVC 6 project and ran into this exact problem.

In MVC 5 and Web API 2, there was a built in way to do it, and even though it was not very extensible, it proved to be very handy (at least for me).

IN MVC 6, these override filters are gone, so at first glance, filter overriding is quite difficult. In reality, that’s not the case, you just need to know what to do - let’s have a look.

Migrating an MVC 5 project to ASP.NET 5 and MVC 6 is a big challenge given that both of the latter are complete rewrites of their predecessors. As a result, even if on the surface things seem similar (we have controllers, filters, actions etc), as you go deeper under the hood you realize that most, if not all, of your pipeline customizations will be incompatible with the new framework.

This pain is even more amplified if you try to migrate Web API 2 project to MVC 6 - because Web API had a bunch of its own unique concepts and specialized classes, all of which only complicate the migration attempts.

ASP.NET team provides an extra convention set on top of MVC 6, called “Web API Compatibility Shim”, which can be enabled make the process of migration from Web API 2 a bit easier. Let’s explore what’s in there.

When working with attribute routing in Web API 2 or MVC 5 it was relatively easy to get the route to the controller and the controller name out of sync. That was because the route always had to be specified as a string, so whenever you changed the name of the controller you would always have to change the string in the route attribute too.

That could be easily forgotten - especially if you use refactoring tools of Visual Studio or an external refactoring plugin.

This issue has been addressed in MVC6 with a tiny addition - the introduction of [controller] ad [action] tokens into attribute routing.

Yesterday the scriptcs project got an little injection of awesomeness through a set of new REPL commands we have added. You can now conveniently access a bunch of contextual information about your REPL session - the idea is to make your work with the REPL smoother, more productive and, of course, more enjoyable. Let’s quickly walk through them in this post.

By the way, it’s a good moment to remind that the REPL command infrastructure is fully extensible - so you can easily build up your own commands. Watch my talk from NDC Oslo if you are interested, there is an example in there.

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.