Open Source .NET – why should you care?

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.

Continue Reading

Using ConfigR as a Configuration Source in ASP.NET vNext

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.

Continue Reading

Building refactoring tools (diagnostics and code fixes) with Roslyn

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.

Continue Reading

Route matching and overriding 404 in ASP.NET Web API

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.

Continue Reading

Over 100 ASP.NET Web API samples

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.

Continue Reading

Things you didn’t know about action return types in ASP.NET Web API

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.

Continue Reading

Strongly typed direct routing link generation in ASP.NET Web API with Drum

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.

Continue Reading

ASP.NET Web API 2: Recipes is out!

ASP.NET Web API 2 Recipes 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.e. attribute routing related), and there are actually a couple of ones in there that only work with ASP.NET Web API 2.2 – so it’s all up-to-date!

It’s been a tremendous journey 9 month journey (the work started in the winter) and there are so many people – the Apress crew, my friends, family, and most importantly, the wonderful ASP.NET community and the readers of this blog, that made it all happen. Thank you – I owe you guys big time!

You can get the book at:

Barnes and Noble

The source code is at Github (I will blog about it separately). And please don’t be too harsh :)

Dependency injection directly into actions in ASP.NET Web API

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.

Continue Reading

Building a strongly typed route provider for ASP.NET Web API

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.

Continue Reading