A while ago we looked at how ApiControllerAttribute can be used in ASP.NET Core MVC to make Web API authoring a little bit more developer friendly.

Today let’s have a look at a tiny little improvement in ASP.NET Core 2.2 - the ability to set it up globally (and perhaps a few other things).

Since the beginning of .NET Core, the one feature that I have been most anxiously waiting for, has been support for collectible assemblies. It took a while (a while!), but finally, in .NET Core 3.0 (at the time of writing 3.0.0-preview-27122-01 from 2018-12-04), it’s here.

It’s going to be a killer functionality, that will support some excellent use cases in .NET Core - especially around application plugins, extensibility and dynamic assembly generation.

Let’s have a quick look at how we can load and unload assemblies in .NET Core.

I am involved in a few open source projects built around the Roslyn compiler. One of those projects is OmniSharp, which brings intellisense and C# language services to a number of editors out there, allowing them to provide for their users a rich C# code authoring experience.

Which actually brings me to the point of today’s post. Roslyn is a compiler-as-a-service that you can embed in your own app, and when you do that, you could reach into its C# language services (more specifically, CompletionService) and easily build your own C# intellisense engine.

However, this is not really documented, so I wanted to use this post to show you how you can get started with that.

It’s that time again, the new dotnet-script release, version 0.27.0 is out. It’s been 2+ months since the last release so this one is fully packed with great features.

You can get it by running dotnet tool install dotnet-script -g (if you don’t have it installed yet) or dotnet tool update dotnet-script -g (if you just need an update).

Let me quickly walk you through some of them.

Both the C# compiler and the CLR/CoreCLR runtimes contain a bunch of rules that are in place to save us from ourselves (and to allow us to write code without needing to fully understand ECMA-334 C# Language Specification). That said, there are times where we want to do some things that are normally not allowed, and a good example of that is reaching into reflection to execute some private or internal code.

Today I wanted to show you how to do something quite cool - how to bypass the type/member visibility rules using the Roslyn compiler. In other words, how to get access to internal and private members without needing to use reflection or something like InternalsVisibleToAttribute.

ASP.NET Core MVC is pretty flexible in terms of how it expects you to return results from the API actions. You could return an IActionResult, which gives you certain control over the status code and the nature of the response (i.e. object or a file or a status code only and so on). You could return a concrete object instance, and the framework will serialize it to the relevant response format. Finally, you could also return the new ActionResult which allows you to mix both of the previous approaches in a single method, giving you the best of both worlds.

Let’s have a look at what happens in the framework when you return a null object instance and how you can change that behavior.

When you are building flexible HTTP APIs, supporting a wide array of different clients, it is common to rely on the process of content negotiation, to allow each client to interact with the API in the most convenient way - be it JSON, XML, Protobuf, Messagepack or any other media type on which both the client and the server can agree.

I have blogged about content negotiation (or in short: conneg) a few times in the past (for example here or here, in ASP.NET Core context). Today I’d like to show you how - in ASP.NET Core - to easily run conneg by hand, instead of relying on the built-in MVC conneg mechanisms.

After a short holiday break, the dotnet-script release train is back at full speed! This week we released 0.26 which can be installed from NuGet - as the .NET CLI global tool - or from Chocolatey.

Let me do a quick roundup of what’s new.

As part of my recent talks on ASP.NET core, I have been showing how to build a custom IFileProvider for ASP.NET Core. The example that I was using was Azure Blob Storage - and exposing files from there as if they were local files that are part of your application.

I have pushed that code to Github and decided to package it as Nuget package, which, hopefully, someone will find useful.

One of the most common things that I have seen developers working with ASP.NET Core struggle with, is the way to centrally and consistently handle application errors and input validation. Those seemingly different topics are really two sides of the same coin.

More often than not, exceptions are just allowed to bubble all the way up and left unhandled, leaving the framework the responsibility to convert them to a generic 500 errors. In many other situations, exception handling is fragmented and happens in certain individual controllers only. With regard to input validation, we often have completely customized ways of notifying the client about input issues or - at best - we leave everything to the framework and let it work its defaults via the ModelState functionality.

What I wanted to show you today is how you can introduce a consistent, centralized way of handling exceptions and request validation in an ASP.NET Core web application.