Tools to let you use Roslyn-powered C# scripts for code generation
Tools to let you use Roslyn-powered C# scripts for code generation
Please note: it's been a while since a Scripty release. I'm not entirely sure when (or if) development on this project will resume. While I would love to pick up development here again at some point, I don't know if it makes sense to dedicate any more time given that the Roslyn team has committed to ship source generators as part of .NET 5.
In the meantime some other projects in this area include:
Also note that the Scripty Visual Studio extension has been removed from the Visual Studio Extension Gallery due to reports of incompatibilities with the most recent versions of Visual Studio. It will be replaced when the next release comes out, but in the meantime you can download it directly from the GitHub version 0.7.4 release page.
Tools to let you use Roslyn-powered C# scripts for code generation. You can think of it as a scripted alternative to T4 templates.
Note that this document corresponds to the currently active source code branch, which may be in development. To view documentation for the latest release of Scripty make sure you are viewing the master branch.
There are two different ways to use Scripty, and they can be used together or separately depending on your use case.
The first is to use the "custom tool" functionality contained in the Scripty Visual Studio extension. Just add that extension to Visual Studio and it's ready to go. Once the extension is installed, you have to "turn it on" for specific files. You do this by manually entering ScriptyGenerator as the "Custom Tool" for a file or files in the project (presumably .csx files, though it'll work for any extension). The "Custom Tool" setting can be found in the file properties in Visual Studio. Once that's set, just right-click on the file and select "Run Custom Tool". Note that the scripts will not be evaluated on every build automatically using this approach.
The other way to use Scripty is with the MSBuild task. In this case, add the Scripty.MsBuild NuGet package to your project. It will automatically pick up any .csx files in your project at build time, evaluate them, and add the results to your compilation. You won't actually see the results in your project. If you want the output of the scripts to show up in the project after using the MSBuild task, you'll need to manually add them after the first build.
I'd recommend looking at the Scripty Visual Studio extension first since it's more obvious when the generation happens and you can immediately see the results. Then once you're comfortable, maybe experiment with the build task. You can also use both together to run code generation on-demand with the custom tool and also on every build with the MsBuild task. Also note that you shouldn't need to install the Roslyn SDK or manually add any of the Roslyn packages or projects to the solution. Everything is self contained in the Scripty extensions and packages.
Scripty scripts are just standard Roslyn C# scripts with some special global properties to make them suitable for powering code generation. All the standard C# scripting conventions still apply such as using the #r preprocessor directive to load assemblies and the #load directive to load external script files. They are also generally given .csx extensions just like normal C# scripts. This makes it easy to bootstrap evaluating them outside Scripty if you need to, providing whichever Scripty globals you use in the script yourself.
It is now also possible to use the #load directive to load c# files (.cs). This makes it convenient to use intellisense when writing files to be used by Scripty. An example of this usage can be seen below.
The following references are added to every script by default:
Microsoft.CodeAnalysis.WorkspacesMicrosoft.BuildScripty.CoreThe following namespaces are imported to every script by default:
SystemScripty.CoreScripty.Core.OutputScripty.Core.ProjectTreeBy default, Scripty looks for files with a .csx extension. This is the same extension used by standard C# scripts and there are a couple reasons why an alternate extension wasn't chosen:
.csx is already recognized by Visual Studio and other tooling as a Roslyn/scriptcs script and so syntax highlighting, Intellisense, etc. will automatically light up. While this could be handled in Visual Studio for a different extension, there are lots of other tools like Visual Studio Code that also have this recognition built-in.If you don't like this behavior, it's easy to change the extension Scripty uses. For the MSBuild task you can change the extension or only process a subset of files by adding an ItemGroup item named ScriptyFile and including whatever files you want the task to process. The custom tool is opt-in to begin with since you have to set the custom tool property. You can have the custom tool process any file, .csx extension or not, by setting the Custom Tool property.
The following global properties are available when evaluating your script with Scripty:
Context
This is a reference to the global ScriptContext class that holds each of the properties described below. You can use it to pass into a method that needs access to the full context. To put it another way, this property holds a class that contains all of the global properties in one object. This can be useful because classes and methods in the script are "lifted" and don't have access to the same global properties unscoped code does.
WritePaths(Context);
public void WritePaths(ScriptContext context)
{
context.Output.WriteLine($"Script File: {context.ScriptFilePath}");
context.Output.WriteLine($"Project File: {context.ProjectFilePath}");
}ScriptFilePath
The full path to the currently evaluating script.
ProjectFilePath
The full path to the current project file.
Project
A leaky abstraction over both the MSBuild API and the Roslyn Workspaces API. This object allows you to traverse a hierarchical model of the project, providing access to the MSBuild ProjectItem and Roslyn Document for any item. This property is a ProjectRoot that exposes other ProjectNode objects by implementing IReadOnlyDictionary (or you can also access child nodes via the Children property).
Analysis
A Roslyn Microsoft.CodeAnalysis.Project that represents the current project. You can use this to access the files in the project as well as other information, including getting the compilation for the project. For example, this script will output comments with the path of each source file in the project:
using Microsoft.CodeAnalysis;
foreach(Document document in Project.Analysis.Documents)
{
Output.WriteLine($"// {document.FilePath}");
}The documentation on Roslyn and specifically the Workspace API isn't great right now. The Roslyn source code browser is a good place to start.
Build
A Microsoft.Build.Evaluation.Project. This API and the Roslyn Workspaces API exposed in the Analysis property have overlapping functionality, but are also complementary. While the Roslyn Workspaces API is more focused on the compilation, the MSBuild API is more focused on the makeup of the project file. Similar to the example for the Roslyn API, this script will output comments with the path of each source file in the project using the MSBuild API:
using Microsoft.Build.Evaluation;
foreach(ProjectItem item in Project.Build.Items.Where(x => x.ItemType == "Compile"))
{
Output.WriteLine($"// {item.EvaluatedInclude}");
}Children
A IReadOnlyDictionary collection that contains the children of the current node.
Parent
The parent ProjectNode.
Name
The name of this node (folder or file name). This is string.Empty for the root node.
ProjectItem
The MSBuild Microsoft.Build.Evaluation.ProjectItem. This is null for the root node.
Document
The Roslyn Microsoft.CodeAnalysis.Document if there is one. Not all project items have a Roslyn document since Roslyn generally only supports source code files at this time. This is null for the root node.
Output
A thin wrapper around TextWriter that should be used to output generated content. Using this object instead of direct file writing mechanisms ensures that Scripty can keep track of which files were generated and pass that information back to the build process as needed. By default, a file with the same name as the script but with a .cs extension is output. A handy pattern is to use script interpolation along with verbatim strings to output large chunks of code at once:
string propertyName = "Bar";
Output.WriteLine($@"
class Foo
{{
int {propertyName} => 42;
}}");Given the above script named script.csx, the following generated code will be output to script.cs:
class Foo
{
int Bar => 42;
}You can output more than one file by using the Output indexer.
Output["other.cs"].WriteLine("// Another file");FilePath
Gets the currently set file path for the output file.
SetFilePath(string filePath)
Changes the file path for the main output file.
SetExtension(string extension)
Sets the file path for the main output file to the same path as the script with the specified extension. Note that if an alternate file path is specified using SetFilePath(), this method will ignore that and will base the new file path on the script file path.
BuildAction
You can also control the build action for the generated file using the BuildAction property. By default, any output file that ends in .cs is compiled and all others are included in the project but not compiled (I.e., a build action of "None"). The BuildAction property takes the following enum:
…For example, to set the build action for the default generated file and an alternate generated file you would write:
```csharp
Output.BuildAction = BuildAction.None;
Output["embedded.xml"].BuildAction = BuildAction.EmbeddedResource;
```Scripty support is provided via a variety of libraries (and corresponding NuGet packages) for different scenarios.
This installs an MsBuild task into your project that will evaluate script files on each build.
By default, all files in the project with the .csx extension are evaluated. You can customize this with the ScriptyFiles ItemGroup (for example, if you have .csx files tha
No open issues yet, or sync has not completed.