#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.

Last week, I set up the code on Github, migrated everything to RC2 and released on NuGet for everyone to use.

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.

Last year at NDC Oslo I did a talk about migrating from ASP.NET Web API to ASP.NET 5 MVC 6 (as it was called at the time).

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.

This post was inspired by the ConfigR library, which provides this type of functionality through scriptcs (I also blogged about ConfigR before).

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.