I was recently working on a project, where I had a need to inherit routes from a generic base Web API controller. This is not supported by Web API out of the box, but can be enabled with a tiny configuration tweak. Let’s have a look.
A couple of months ago I blogged about adding a feature to ASP.NET Core MVC (or ASP.NET 5 at the time) that will allow you to set central route prefix(es) to your attribute routing mechanism.
That solution was written against beta8 version of ASP.NET Core and since now we are at RC2 – it doesn’t (surprise, surprise) work anymore.
Here is the updated version.
One of the side projects I created for Web API a while ago was Strathweb.TypeRouting – a little library built on top of the attribute routing extensibility points, that allowed you to declare Web API routes centrally, in a strongly typed way (as opposed to the built in, anonymous object approach).
Then, some time ago, I blogged about how you would achieve the same thing in ASP.NET Core. A bunch of things have changed since then – the original post was written against beta6 of the framework I believe.
Over the past 4 years or so, I have worked on many Web API projects, for a lot of different clients, and I thought I have seen almost everything.
Last week I came across an interesting new (well, at least to me) scenario though – with the requirement to run two Web API pipelines side by side, in the same process. Imagine having /api as one Web API “instance”, and then having /dashboard as completely separate one, with it’s own completely custom configuration (such as formatter settings, authentication or exception handling). And all of that running in the same process.
More after the jump.
One of the functionalities I had to use fairly often on different ASP.NET Web API projects that I was involved in in the past was IP filtering – restricting access to the whole API, or to parts of it, based on the caller’s IP address.
I thought it might be useful to share this here. More after the jump.
In this post we will have a look at how, with just several lines of Roslyn code, you can build an extremely cool and powerful utility – a library allowing you to provide configuration for your application as a strongly typed C# script file.
We will, however, deal with marshalling configuration data between the C# configuration and the parent app differently than ConfigR does.
In the “classic” ASP.NET, System.Web.HttpRequest gave us a fairly useful IsLocal property which developers used to identify local requests.
It returned true if the IP address of the request originator was 127.0.0.1 or if the IP address of the request was the same as the server’s IP address.
ASP.NET Core RC1 exposed similar type of information on its ConnectionInfo object (hanging off HttpContext) and via an IHttpConnectionFeature. However, this is being removed in RC2.
Let’s see how you can quickly add it back as extension method, so that you can use it going forward.
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.
Yesterday, at Build, Microsoft released the first public preview of Visual Studio “15” – the next iteration of Visual Studio.
One of the main reasons why you’d want to try it out already is to be able to use some of the heralded C# 7 features – such as binary literals, local functions or pattern matching (to name just a few).
It’s been possible to test out these features in a slightly hacky way before (see Josh’s post) – by building Roslyn from source and deploying it into VS using the CompilerExtension VSIX, but of course it’s much easier and convenient to just use C# 7 features directly in VS “15” now.
In this post I’m gonna show you how to enable the experimental C# 7 features – because they are by default not available.
Some time ago I wrote a blog about how ASP.NET MVC 6 discovers controllers. While a lot has change since then, including the name – now the framework being called ASP.NET Core MVC, the post is still valid and the processes described there haven’t really changed.
That said, there is one extra thing that should be added to it, and that is how external dependency injection containers relate to the process of controller discovery and instantiation, as there is a subtle difference between ASP.NET Core MVC and the “classic” frameworks – MVC 5 or Web API 2. This post is really sparked by the conversation on Twitter with Jeremy and Kristian.