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.

There is a ton of great material on the Internet about dependency injection in ASP.NET Web API. One thing that I have not seen anywhere though, is any information about how to inject dependencies into the action, instead of a controller (constructor injection).

Injecting your dependencies directly into an action, rather than in the controller is a very reasonable approach, as it helps you falling into an over-injecting trap, and perhaps resolving too much things, for no real reason.

With Web API, it’s actually extremely easy to do, so let’s go ahead and implement it.

More after the jump.

ASP.NET Web API 2.2 was released last week, and one of the key new features is the ability to extend and plug in your own custom logic into the attribute routing engine.

Commonly known as “attribute routing”, it’s actually officially called “direct routing”, because, as we are about to show here, it’s not necessary to use it with attributes at all, and you can plug in any route provider into it.

More after the jump.

Sublime Text is by far my favorite text editor. In its rich ecosystem of plugins you can find some absolute gems, and one of those is SublimeREPL which adds support for REPLs of various programming languages directly into your Sublime Text.

Swift is missing from there - but let’s add support for it!

One of the big advantages of Swift is that it gives you access to all Cocoa APIs and lets you use them in some very flexible ways.

One of those is the possibility to use Swift as a general OS “scripting” language - instead of bash, PyObjC or C or any other option that you might have opted for in the past. Moreover, you can do that entirely from outside of XCode - so write your Swift program in any editor and then simply use Terminal to execute it, as if it was pure script.

The obvious advantage of such approach is that you now have the same single language to handle iOS programming, OS X app programming and generic system/automation tasks that you might want to perform from the command line.

Let’s have a look.