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.
#load directives in C# scripts are intended to allow you to reference a C# script source file from another C# script. As an author of a host application, in which the Roslyn scripting would be embedded, it’s up to you to define how #load should behave.
Let’s have a look at the process of doing that.
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.
The talk was done against the beta 6 version of the runtime, so release-wise, it was quite a way back.
To celebrate today’s release of ASP.NET Core RC2, I have updated the code samples from the talk to that RC2 version. Hopefully folks would still find it useful.
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.