Last year I blogged about a way to handle NuGet package versions at the solution level for .NET SDK-based csproj project files (so those using entries to define their NuGet dependencies).

That approach worked reasonably well, but was entirely custom - as it simply relied on defining reusable MsBuild properties to handled the versions, which created a bit of overhead.

With MsBuild 15 and newer, you can actually do it in a much more elegant way. Let’s have a look.

I was working on an interesting issue in an ASP.NET Core recently. An external framework was responsible for creating an HTTP Response, and I was only in control of a little component that customized some internal behaviours (via a relevant extensibility point), without being able to influence the final response sent over HTTP.

This is common if you think about extending things like CMS systems or specialized services like for example Identity Server. In those situations, more often than not, the framework would be highly opinionated in what it is trying to do at the HTTP boundaries and as a result, trying to override the HTTP status codes or headers it produces may not be easy.

Let’s have a look at a simple generic workaround.

It is common to leverage action filters when building MVC applications - this was the case in classic ASP.NET MVC, in ASP.NET Web API and is a still widely used technique (with much richer support!) in ASP.NET Core MVC.

What is not commonly known though, is that it’s possible for controllers to act as their own filters - so let’s have a look at this feature today.

A few years ago I blogged about dependency injection directly into actions in ASP.NET Web API. The idea is quite simple - instead of injecting all of your dependencies via the controller’s constructor, you can inject them as parameters into the action handling a given HTTP request.

This can help you prevent over-injection in the constructor; I also like this approach because it’s very verbose and clear - an action explicitly manifests what it needs to handle the request and gets just that, nothing more.

It actually works out of the box in ASP.NET Core, so let’s have a look at that and some related configuration.

In the previous post, I announced that dotnet-script is now built as global tool and can be installed using .NET Core 2.1 preview SDK. However, by that time it was still based on .NET Core 2.0 runtime (it was possible to build and install .NET Core 2.0 tools using .NET Core 2.1 preview SDK).

Now we have even more cool news to announce - because dotnet-script is now a true .NET Core 2.1 application, and can be used to run scripts on top of .NET Core 2.1 runtime. We release quite often so let me do a quick rundown of all the new features since my last blog post.

Yesterday we released version 0.20.0 of dotnet-script - a command line tool that allows you to run C# scripts (.csx) in the .NET Core runtime.

The highlight of this release is that it is now avaialble as .NET Core SDK 2.1 global tool, which provides an excellent acquisition/installation story directly from nuget.

One of those recurring themes that seem to come back fairly regularly among .NET web developers, is the usage of generic controllers to define endpoints in their Web APIs. I have witnessed these discussions as part of ASP.NET MVC, then ASP.NET Web API and most recently in ASP.NET Core MVC.

While I don’t necessarily see a huge need or benefit for generic controllers, I can imagine that - especially in enterprise context - there are scenarios where exposing similarly structured, “cookie-cutter” CRUD endpoints quickly and seamlessly, could possibly have some business value.

Let’s have a look at generic controllers then, and how we could also dynamically feed types into them.

Today I wanted to show you something that I hope could be a very useful addition to your .NET Core development toolbox, and that is an ultra-lightweight of doing performance benchmarking for your code using BenchmarkDotNet and dotnet-script.

We just released 0.19.0 of dotnet-script, that supports benchmarking, yesterday.

ASP.NET Core MVC 2.1 will ship with a nice little feature aimed specifically at people building HTTP APIs - ApiControllerAttribute. While the stable release of 2.1 is not yet here, we can already have a look behind the scenes - what is this feature doing, and how can it help you write Web APIs.

I’ve worked on quite a lot of projects over the years, with many different teams, and one of the questions that keeps coming back to me over and over with a high degree of regularity is how to load a C# lambda from a string - for example from a configuration file.

This is not surprising, because being able to do that can give you a tremendous amount of flexibility in your code, as it would (for the lack of better word) unlock the possibility to alter business logic from the configuration level, without having to recompile and redeploy your application.

Historically, this has been possible but also quite a painful task. Today I wanted to show you a remarkably simple solution to this problem - with the help of the Roslyn compiler Nuget packages.