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.
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 <MvcBuildViews>true</MvcBuildViews> 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.
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.