Roslyn-Based DSLs vs. Standard C# Scripts
One of the many benefits of the Roslyn compiler-as-a-platform approach is that we can use it within our own applications to enable interesting scenarios like code-based configuration or scriptable behaviors. Roslyn provides several facilities for making this possible including a compilation API, access to syntax and semantic information, and a dedicated scripting API. In addition, Roslyn also powers the execution of C# scripts (typically ending in the .csx extension) by providing a script runner executable that's basically a thin wrapper around the scripting API I just mentioned. This gives developers many different options for how to introduce the power of code-driven functionality to their codebase. This post takes a look at two such options and why you might want to use one over the other. We'll also consider some of the fundamental reasons why there are tradeoffs at all and what could be done to improve the situation.
Announcing Scripty
I've written a lot of T4 templates, and while they work well enough for compile-time code generation, they're never much fun to write. Recently however I've noticed an even bigger problem with T4 templates now that Visual Studio is becoming less and less a required part of the build process (more on this in a minute). Thankfully, the Roslyn team has done an excellent job of packaging the Roslyn compiler into an easy to consume scripting package. By combining that scripting support with some Visual Studio extensibility, we can provide a code generation alternative that relies on Roslyn scripts written in plain old C# (VB.NET script support coming soon).
Introduction to Scripting with the .NET Compiler Platform (Roslyn)
Scripting support in the .NET Compiler Platform (formerly known as Roslyn) has been a long time coming. It was originally introduced more than a year ago and then removed while the team considered what the ideal API should look like. It was recently reintroduced into the master source branch on GitHub, though as of this blog post it still isn't available on the nightly MyGet feed or on NuGet. In this post I will explain how to obtain and build the new scripting bits (including on a system without Visual Studio 2015 - it can actually be built using only Visual Studio 2013), introduce some of the scripting functionality, and show some scenarios where this might be helpful in your own applications. I also want to caveat this post by saying that it may go out of date quickly. The .NET Compiler Platform is under heavy development and it is changing frequently, including the public API. While I wouldn't expect any sweeping changes in the scripting support at this point, many of the details are subject to change.