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.
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.
In this post I wanted to share a little project I’ve been working on recently – a .NET CLI and .NET Core based script runner for C# (CSX scripts).
The idea was super simple – I just wanted to be able to author C# scripts using .NET Core, leverage project.json to define the script dependencies and execute scripts cross platfom using .NET CLI – via a dotnet script command.
Last month I was at the excellent NDC Sydney conference, where I did a talk about building code analyzers and refactoring tools with Roslyn. Below you can find the the video, code and slides from the session.
Thanks to everyone who attended – I had great fun, and I was even mugged by a kangaroo afterwards.
You can watch the talk on Vimeo. And if you are wondering, yes, my t-shirt says “#ENDREGIONS”.
All the demo code is hosted at Github>.
#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.
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.
We will, however, deal with marshalling configuration data between the C# configuration and the parent app differently than ConfigR does.
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.
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.