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.

Today I have released a new version of Strathweb.TypedRouting.AspNetCore. This new version is built as .NET Standard 2.0, and - obviously - finally supports ASP.NET Core MVC 2.

Here is a short summary and some links to help you get started.

When controlling the binding behavior of models in ASP.NET Core MVC applications, it is very common to perform some validation on them. For that, data annotations are a perfect tool.

One of the most typical use cases of data annotations is to ensure that a value of a certain property has been provided by the caller of the API - and this, historically (in “classic” ASP.NET MVC), has been controlled by RequiredAttribute. The attribute can still be used in ASP.NET Core MVC, but there is also a new one - BindRequiredAttribute.

Let’s have a look at the subtle differences between them.

Last week, together with [Bernhard][1] we released version [0.16 of dotnet-script][2], the .NET Core 2.0 C# script runner. I’d like to summarize the new features in this short blog post - as there are two highlights of this release - which we are very excited about!

The project now offers a C# REPL (interactive mode) which can be access when launching dotnet-script without any arguments. All the features of scripting are supported in the interactive mode, including support for adding Nuget references via #r “nuget: {package}”.

The second large feature is support for #load “nuget: {package}”, which works similar to its #r counterpart, except not for assemblies but for referencing CSX files from Nuget.

As you may have read on this blog before, together with Bernhard, we have been working on a .NET Core and .NET CLI C# script runner, called dotnet-script, for a while now. Today I have a big announcement to make - we have recently released .NET Core 2.0 and .NET Standard 2.0 support!

These changes are part of 0.14.0 release that came out 3 weeks ago. We didn’t want to promote it that much, because - as it’s normally the case with .NET Core related stuff - the accompanying tooling wasn’t ready. In other words, there was no robust language services or intellisense story for writing .NET Core 2.0 scripts.

However, we are now ready with OmniSharp tooling too, which means you can enjoy C# scripting on .NET Core 2.0 in VS Code as long as you install the latest beta release of C# for VS Code. In parallel, we also already released a 0.15.0 version of dotnet-script.

Here is how to get started and a summary of what is new in 0.14.0 and 0.15.0.

When building logic around the IdentityServer4 extensibility points, it is sometimes necessary to dynamically issue a token, with which your code can then call some external endpoints or dependencies.

Turns out that rather than round-tripping back to same IdentityServer4 instance over the network to get that token, there is a more efficient and quicker way to do it. Let’s have a look.

In this blog post I’d like to show you a very simple technique for ensuring all your Nuget packages across all the projects in a solution have the same version. Such package management improvement introduced recently into the OmniSharp code by one and only Dustin Campbell, and I’ve also been using it in some of my projects.

If your solution is built around .NET SDK csproj projects, which were introduced in Visual Studio 2017, hopefully this blog post will be useful to you.