IP Filtering in ASP.NET Web API

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.

Building strongly typed application configuration utility with Roslyn

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.

Request.IsLocal in ASP.NET Core

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.

Predefined Namespaces And Custom Base View Page in ASP.NET Core 1.0 MVC

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.

Enabling C# 7 Features in Visual Studio “15” Preview

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.

The Subtle Perils of Controller Dependency Injection in ASP.NET Core MVC

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.

Roslyn scripting on CoreCLR (.NET CLI and DNX) and in memory assemblies

For a while now, the Roslyn C# scripting APIs (Microsoft.CodeAnalysis.CSharp.Scripting) have been portable, and supported cross platform usage.

However, I recently ran into a few difficulties regarding using the Roslyn Scripting APIs in .NET CLI (which is replacing DNX) context. The solution was to use a lower level unmanaged CoreCLR API - and since they it’s not that well documented, I thought it would be beneficial to document it in a blog post.

OmniSharp Canada Tour 2016

I’ve said it a couple of times already, but I sincerely believe that the OmniSharp project is one of the most important projects in the history of .NET. Having an alternative to the “dictatorship” of Visual Studio is fundamentally important to the health of the .NET ecosystem, and OmniSharp has done a tremendous job in that sense (thanks, Jason & David). Fro my side, I’ve been trying to support the project as much as I can - by contributing, speaking or blogging about it, trying to spread the love.

FormatFilter and MediaTypeMappings in ASP.NET Core 1.0 MVC

In the earlier posts, we looked at how formatters work in general in the upcoming MVC Core 1.0 (although at that time it was still being referred to as MVC 6) and how XML formatters can be enabled in your ASP.NET Core application.

This time around, I thought it would be interesting to follow up on that, and discuss another topic that should be very familiar to folks with ASP.NET Web API experience - MediaTypeMappings. They were quite commonly used in Web API, and they have been ported over to MVC Core, and can be enabled via a FormatFilter.

Re-using external view components in ASP.NET 5 & ASP.NET MVC 6

The other day we [explored using view components in ASP.NET 5][1] - as a very nifty replacement for the old MVC ChildActions. View components allow you to package a piece of functionality into a reusable class, along with an accompanying view, that can be invoke from any other view on demand.

Today let’s take this a step further - and let’s see how you can configure ASP.NET MVC 6, to be able to consume view components not just from the current web project but from external sources - external assemblies too. This way you will be able to share and distribute your view components across multiple projects. This is definitely useful for anyone who has - for example - ever worked on a portal-style applications, where building reusable components is one of the most important development activities.

About


Hi! I'm Filip W., a software architect from Zürich 🇨🇭. I like Toronto Maple Leafs 🇨🇦, Rancid and quantum computing. Oh, and I love the Lowlands 🏴󠁧󠁢󠁳󠁣󠁴󠁿.

You can find me on Github, on Mastodon and on Bluesky.

My Introduction to Quantum Computing with Q# and QDK book
Microsoft MVP