Asp.net Mvc on Strathweb. A free flowing tech monologue.

Centralized exception handling and request validation in ASP.NET Core

Mon, 30 Jul 2018 16:22:13 +0000

One of the most common things that I have seen developers working with ASP.NET Core struggle with, is the way to centrally and consistently handle application errors and input validation. Those seemingly different topics are really two sides of the same coin.

More often than not, exceptions are just allowed to bubble all the way up and left unhandled, leaving the framework the responsibility to convert them to a generic 500 errors. In many other situations, exception handling is fragmented and happens in certain individual controllers only. With regard to input validation, we often have completely customized ways of notifying the client about input issues or - at best - we leave everything to the framework and let it work its defaults via the ModelState functionality.

What I wanted to show you today is how you can introduce a consistent, centralized way of handling exceptions and request validation in an ASP.NET Core web application.

[Required] and [BindRequired] in ASP.NET Core MVC

Thu, 21 Dec 2017 14:30:21 +0000

When controlling the binding behavior of models in ASP.NET Core MVC applications, it is very common to perform some validation on them. For that, data annotations are a perfect tool.

One of the most typical use cases of data annotations is to ensure that a value of a certain property has been provided by the caller of the API - and this, historically (in “classic” ASP.NET MVC), has been controlled by RequiredAttribute. The attribute can still be used in ASP.NET Core MVC, but there is also a new one - BindRequiredAttribute.

Let’s have a look at the subtle differences between them.

Customizing query string parameter binding in ASP.NET Core MVC

Fri, 21 Jul 2017 13:55:42 +0000

A few years ago I blogged about binding parameters from URI in ASP.NET Web API. One of the examples in that post was how to bind a comma-separated collection passed to your API as a query string parameter.

Technologies change, and we now work with ASP.NET Core (and the MVC Core framework), but problems remain the same - so let’s have a look at how we can customize the way parameters are bound from query string in ASP.NET Core MVC.

Using IActionConstraints in ASP.NET Core MVC

Tue, 20 Jun 2017 14:02:03 +0000

ASP.NET Core provides a way to constraint parameter values when matching routes via an IRouteConstraint (read more here) interface. This can be very useful, if you want to disambiguate certain routes from one another. This functionality is built into the routing package and is independent from the MVC framework.

However, aside from that, the MVC framework itself also provides an interesting constraint-mechanism - IActionConstraints. Let’s have a look at them today.

Running multiple independent ASP.NET Core pipelines side by side in the same application

Fri, 07 Apr 2017 09:17:39 +0000

The other day I started looking into a problem of being able to run several independent ASP.NET Core pipelines from within the same main application, running on top of the same Kestrel server. This was actually asked on MVC Github repo but closed without a real answer.

Let’s have a detailed look at the problem, and (one) possible solution to it.

Required query string parameters in ASP.NET Core MVC

Mon, 19 Sep 2016 15:26:02 +0000

Today let’s have a look at two extensibility points in ASP.NET Core MVC - IActionConstraint and IParameterModelConvention. We’ll see how we can utilize them to solve a problem, that is not handled out of the box by the framework - creating an MVC action that has mandatory query string parameters.

Let’s have a look.

[Controller] and [NonController] attributes in ASP.NET Core MVC

Thu, 08 Sep 2016 15:08:41 +0000

One of the late additions before the RTM release of ASP.NET Core MVC was the introduction of the [Controller] attribute, and its counterpart, [NonController], which were added in RC2.

Together, they allow you to more specifically control which classes should be considered by the framework to be controllers (or controller candidates) and which shouldn’t. They also help you avoid the nasty hacks we needed to do in i.e. ASP.NET Web API to opt out from the “Controller” suffix in the name.

Let’s have a look.

Customizing FormatFilter behavior in ASP.NET Core MVC 1.0

Wed, 06 Jul 2016 18:57:33 +0000

When you are building HTTP APIs with ASP.NET Core MVC, the framework allows you to use FormatFilter to let the calling client override any content negotiation that might have happened on the server side.

This way, the client can - for example - force the return data to be JSON or CSV or any other format suitable (as long as the server supports it, of course) for his consumption.

The built-in mechanism (out of the box version of FormatFilter) is a little limited, so let’s have a look at how you can extend and customize its behavior.

Predefined Namespaces And Custom Base View Page in ASP.NET Core 1.0 MVC

Fri, 08 Apr 2016 00:06:44 +0000

It is quite common to predefine some namespaces to be available in the context of your Razor view files in ASP.NET MVC. In MVC 5, it was done inside the web.config file - not the “main” application one, but the one residing inside your Views folder.

Additionally, the same file was used to define the pageBaseType for your Razor views. This way you could expose extra members or behaviors to your pages, such as injected services or common configuration objects.

Since there is no more web.config in ASP.NET Core 1.0 MVC, let’s have a look at how to achieve the same in the next generation ASP.NET.

ASP.NET MVC 6 formatters – XML and browser requests

Fri, 24 Apr 2015 11:32:15 +0000

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.

How ASP.NET MVC 6 discovers controllers?

Wed, 01 Apr 2015 09:58:29 +0000

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.

Strongly typed routing for ASP.NET MVC 6 with IApplicationModelConvention

Wed, 11 Mar 2015 18:28:27 +0000

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.

Overriding filters in ASP.NET MVC 6

Thu, 12 Feb 2015 11:05:48 +0000

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 from ASP.NET Web API to MVC 6 – exploring Web API Compatibility Shim

Wed, 21 Jan 2015 12:59:52 +0000

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.

ASP.NET MVC 6 attribute routing – the [controller] and [action] tokens

Wed, 07 Jan 2015 12:28:29 +0000

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.

Formatters in ASP.NET MVC 6

Mon, 17 Nov 2014 12:01:30 +0000

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.

POCO controllers in ASP.NET vNext

Wed, 11 Jun 2014 09:34:38 +0000

One of the very cool features of the vNext of ASP.NET MVC (a unified framework set to succeed MVC, Web API and Web Pages) is the ability use POCO classes as controllers. No base class, no interface to implement, 100% convention.

Let’s look a little bit into that.

Adding Session support to ASP.NET Web API

Fri, 09 Nov 2012 04:11:36 +0000

First the disclaimer. Yes, there are a lot of problems with using session in your ASP.NET applications. Moreover, by default, HTTP (and by extension, REST) is stateless - and as a result each HTTP request should carry enough information by itself for its recipient to process it to be in complete harmony with the stateless nature of HTTP.

So if you are designing a proper API, if you are a REST purist, or if you are Darrel Miller, you definitely do not want to continue reading this article. But if not, and you find yourself in a scenario requiring session - perhaps you are using Web API to facilitate your JS or MVC application, and you want to sync the state of Web API with the state of MVC easily, or you simply want a quick and easy way to persist state on the server side - this article is for you.

More after the jump.

Supporting OData $inlinecount with the new Web API OData preview package

Thu, 23 Aug 2012 11:43:02 +0000

OData support in Web API is arguably one of its hottest features. However, it’s support in Web API has been a bumpy ride - initially, OData was supported in a limited way only, and ultimately ended up being yanked altogether from the Web API RTM. It is however stil lpossible to use OData with Web API, only in a slighly different form , as an [external NuGet package][1], which, in its pre-release alpha format was published last Wednesday, along the Web API RTM release.

This package is called Microsoft ASP.NET Web API OData and is a joint effort by Microsoft’s Web API and OData teams. Alex James has written a [great introduction][2] to the package, so I recommend reading it.

In the meantime, let me show you how to add $inlinecount support as for the time being, it’s still not provided there out of the box.

ASP.NET Web API is released! What’s new in Web API RTM and how to use it!

Wed, 15 Aug 2012 17:32:46 +0000

If you have been following this blog for a while now (and if not, I really hope you will!), you’d know that I am a big fan of Web API. I have been blogging a lot about Web API, through its beta, RC stages and even about features that were only available through the Codeplex builds and I have to say that it is a terrific bridge between CLR and HTTP and fits really nicely into the existing landspace of web technologies.

With that said, today is a really big and important day, as Web API has been publicly released in its RTM version. This effectively means that you have binaries you can safely use in production scenarios and take advantage of all the great features of the framework. You can [download MVC4 (including Web API) RTM here][1].

Let’s go through the new features in RTM.

Testing routes in ASP.NET Web API

Sun, 12 Aug 2012 09:10:30 +0000

The question that often comes up when talking to developers and clients about Web API solutions is how exactly should you go about testing your route configuration in Web API? Some would perhaps argue that in certain cases, especially if you stick to RESTful approach, this type of testing wouldn’t even be necessary, because the convention over configuration provided by the framework means that you effecitvely end up testing something that’s internal working of Web API.

With that said, especially when you have complex routes, or when you break the Restful approach and provide RPC-style API, or if you have your API actions decorated with HTTP verbs that don’t match the action names, you probably want to (and probably should, if you ask me) test the API routing to make sure certain requests end up in proper places.

Let’s deal with this interesting problem.

Adding OpenID authentication to your ASP.NET MVC 4 application

Wed, 01 Aug 2012 20:18:05 +0000

I am currently working on an MVC4 project that allows users to authenticate through OpenID. I don’t think I need to convince anyone about the benefits for both parties that come with that. Users don’t have to register at your site, and you have less of those tedious account maintance tasks.

Although it’s apparently coming later on as a built-in feature into the Visual Studio templates (Damien Edwards showed that stuff for Web Forms during aspConf), let me show how you can very quickly add simple OpenID support to your MVC4 application.

More after the jump.

Everything you want to know about ASP.NET Web API content negotiation

Sun, 15 Jul 2012 16:04:21 +0000

One of the key concepts in ASP.NET Web API, lying pretty much at the heart of it, is content negotiation - or simply conneg. I really believe that, before you start developing Web API solutions, you need to understand conneg well.

I thought it would be interesting to try to explain content negotiation in detail - what it is, what it does, and why it does that, especially as I have seen a lot of questions, misconceptions and misunderstandings around it on various boards or question sites.

Using NLog to provide custom tracing for your ASP.NET Web API

Mon, 25 Jun 2012 17:41:01 +0000

One of the things I love most about MVC3, and now ASP.NET Web API, is that pretty much any functionality or service that is used by your application, can be replaced with a custom one. One of these is the entire tracing mechanism that Web API uses.

Let’s have a look today at how you can build a simple System.Web.Http.Tracing.ITraceWriter implementation to provide support for a custom logging framework in your Web API - in our case it will be NLog.

More after the jump.

ASP.NET Web API integration testing with in-memory hosting

Tue, 12 Jun 2012 16:47:30 +0000

In-memory hosting is one of the hidden gems of ASP.NET Web API. While the community, forums, bloggers have been buzzing about web-host and self-host capabilities of Web API, aside from the terrific post by Pedro Felix, very little has been said about in memory hosting.

Let me show you an example today, how a lightweight Web API server can be temporarily established in memory (without elevated priviliges, or cannibalizing ports like self host) and used to perform integration testing, allowing you to test almost the entire pipeline, from the request to the response.

Control the execution order of your filters in ASP.NET Web API

Fri, 08 Jun 2012 16:00:31 +0000

One of the few minor annoyances in ASP.NET Web API is that you lack the ability to control the order in which the attributes/filters are executed. If you have several of those applied to one action, they will not run in the order they have been declared in the code, and that sometimes may cause a lot of problems.

In fact, as a member of the ASP.NET Web API Advisory Group I already brought that up during our meetings, not to mention it has already been submitted as an issue to the ASP.NET team on Codeplex. In the meantime, let’s tackle this problem and see how you can easily regain control over the execution order of the attributes.

Extending your ASP.NET Web API responses with useful metadata

Sun, 03 Jun 2012 13:27:13 +0000

If you ever worked with any API, which, in this day of age, you must have, you surely noticed that in most situations the API response isn’t just the result (requested data), but also a set of helpful metadata, like “total Results”, “timestamp”, “status” and so on.

In Web API, by default, you just serialize your models (or DTO) and such information are not present. Let’s build something which will solve this problem and help you decorate your response with hepful information. This would make it very easy for the client to implement paging, auto-loading scenarios, caching (if you return last modified information) and a lot more.

Using Ninject with the latest ASP.NET Web API source

Sun, 27 May 2012 09:24:51 +0000

After ASP.NET Web API was beta-released in February, a number of blog posts came out explaining how to plug Ninject (and other IoC-s, for that matter) to your application through the use of the IDependencyResolver adapter. There was even a NuGet Ninject extension for that (here).

However, these approaches don’t work anymore if you are using the latest ASP.NET Web API (and release candidate) - either from Codeplex source or nightly build packages.

Let’s explore why is that and what you need to do now to be able to use Ninject with ASP.NET Web API.

Attribute based routing in ASP.NET Web API

Wed, 23 May 2012 20:05:34 +0000

Routing is the key aspect of every MVC application - after all, it’s how people get to your application, and how search engines see it. As flexible as routing in ASP.NET MVC has been, one would often end up in frustrating situations where more flexibility was needed (or you simply started getting lost in a maze of routes). One of the finest extensions to ASP.NET MVC I have ever worked with is the excellent library AttributeRouting by Tim McCall.

Last month, through the great work of Kamran Ayub, the library has been extended to support ASP.NET Web API, and is now available on NuGet. Let’s have a look at how it can immediately make your life easier and drastically improve the way you handle your routes.

Implementing message handlers to track your ASP.NET Web API usage

Wed, 16 May 2012 20:49:01 +0000

Today’s focus is going to be on message handlers (or, to be precise, DelegatingHandlers) in ASP.NET Web API. If you are familiar with WCF you can surely recall them - used to be called DelegatingChannels at some point - but the purpose has been the same all along, to provide the first (or last, depending whether you look at requests or responses) extendibility point in your Web API applications. You stack up as many message handlers on top of each other as you wish, and the request will travel through all of them.

This, in turn, gives us developers a possibility to process/alter/modify/decline the incoming HTTP request before it reaches the HttpControllerDispatcher. Then, when the controller creates the response, it goes through the same chain of message handlers again, so we can tamper with the response. One example of the applicability of this is that message handlers are a perfect place to address security related matters i.e. integrating OAuth.

The plan for today is to show how DelegatingHandlers are used by building a functionality that checks for an API key on an incoming API request and then logs all requests and responses, thus allowing you to track the usage of your API.

Output caching in ASP.NET Web API

Thu, 10 May 2012 16:46:17 +0000

Today we will continue with our favorite topic - ASP.NET Web API. I’ve heard folks asking about how you could easily cache the output of the API methods. Well, in ASP.NET MVC, that’s dead easy, just decorate the Action with [OutputCache] attribute and that’s it. Unfortunately, ASP.NET Web API doesn’t have a built-in support for this attribute.

Which doesn’t mean you can’t have it. Let’s build one

Native HTML5 push notifications with ASP.NET Web API and Knockout.js

Sun, 06 May 2012 14:19:08 +0000

The ASP.NET Web API project progresses at a rapid pace, and has already come a long way since the beta release. And as it is OSS now, it’s really great that we all can see the progress being made (thanks, MS!). So today we are going to build a native HTML5 push notifications mechanism over HTTP protocol, utilizing the latest exciting features of Web API (PushStreamContent), modern browsers’ Server-sent Events EventSource API and, of course, Knockout.js.

Few weeks ago Henrik Nielsen on his blog was kind enough to share some updates about the latest feauters available in the ASP.NET Web API. We are going to be using his sample code as the starting point to develop an application utilizing a real HTTP push messaging infrastructure. We’ll use that to build a browser-based multi-person chat, but the principles showed here could be used for pretty much anything that requires pushing content to the client.

Different MediaTypeFormatters for same MediaHeaderValue in ASP.NET Web API

Fri, 27 Apr 2012 15:39:39 +0000

Let’s say you have a model and want to serve it through a different MediaTypeFormatter from different controllers or routes or urls? You want same content type (MediaHeaderValue) request, to be formatted differently in different situations - how could you do that, if everything resides in GlobalConfiguration?

It would be perfect to be able to use per-controller configuration in ASP.NET Web API. Unfortunately, at this stage, this feature is not yet supported. Henrik mentioned that Mike Stall is currently working on this, and it will be supported in the full release on Web API (perhaps even earlier, on codeplex?).

Anyway, let’s take this idea for a spin and explore what we could do in beta version of ASP.NET Web API, because we could still vary our formatters and responses.

RSS & Atom MediaTypeFormatter for ASP.NET WebAPI

Sun, 22 Apr 2012 12:53:12 +0000

Today we are going to build a custom formatter for ASP.NET WebAPI, deriving from MediaTypeFormatter class. It will return our model (or collection of models) in RSS or Atom format.
The Formatter is supposed to react to requests sent with request headers “Accept: application/atom+xml” and “Accept: application/rss+xml”.

Let’s get going.

HTML5 drag and drop asynchronous multi file upload with ASP.NET WebAPI

Wed, 04 Apr 2012 21:53:20 +0000

Today we are going to build a neat HTML5 file uploader using ASP.NET Web API and jQuery. We are also going to include knockout.js to keep the list of uploaded files updating smoothly in real time.

In addition to all that, we will leverage on HTML5 drag and drop events , as well as HTML5 File API, to provide the file input to the application. Finally, we will use FormData JS interface to build up the request, and we will use ApiController of our ASP.NET MVC 4 application to pick up the files and save them on the server using an instance of MultipartFormDataStreamProvider.

More after the jump.