It is the biggest release yet – with the highlight feature being the ability to use inline Nuget packages.
Here is the overview of what’s in there.
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.
As part of my efforts to popularize C# scripting in the .NET community (which, hopefully, you have noticed by following this blog, my Twitter or my Github) and in celebration of the first stable release of Roslyn scripting packages on Nuget yesterday, I published a guest post at Canadian Developer Connection blog – Adding C# Scripting to Your Development Arsenal.
You can read the post here, and hopefully you find it useful. It’s part 1 of a short 2-piece series.
Last year, during a few of my Roslyn talks, I was presenting a cool idea of leveraging Roslyn in unit tests to enforce a certain style in code, and in general inspect the consistency of the code in various ways.
It’s a really powerful concept, and something I wanted to blog about, but of course forgot – until I was reminded of that yesterday on Twitter.
Let’s have a look.
While out of the box, DNX only compiles proper, traditional C# only, thanks to the compilation hooks it exposes, it is possible to intercept the compilation object prior to it being actually emitted, which allows you to do just about anything – including run C# scripts.
Let’s explore more.