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.
Export to an executable π
You can export the script into an executable for a given platform. This feature is called publish, and the goal is to be able to produce a standalone program out of your script. Once an executable is published, it is fully portable (a self contained application) and doesn’t require .NET SDK to be present on the machine anymore. This is the same as publishing a .NET Core Console Application to a self contained application (uses same machinery under the hood), with the obvious difference being that your “input” is not a Console App but a CSX script.
It is used by invoking the following command:
dotnet script publish <path to your csx> --output <output folder> --runtime <runtime identifier i.e. osx-x64>
The default output folder is the ./publish folder in the current directory and the default runtime identifier is the one of your current platform. You can see the full help for this feature using dotnet script help publish. The feature supports using the inline NuGet packages, so if you have external dependencies from NuGet they will simply get bundled with the output.
I hope this can be useful and that it would give you more flexibility in terms of deciding how you’d want to distribute your scripts.
Export to a DLL π
In a similar fashion to building an executable program, you can also publish to a DLL, and then use that DLL to run your script. In a loose analogy, you can think of this feature as a “cache” of a script, allowing you to run the script faster, as it will not get internally recompiled.
It is used by invoking the similar command as publishing to executable, except you need to pass the -dll flag too:
dotnet script publish <path to your csx> --output <output folder> --dll
Once a DLL is ready, you can run your script from the DLL using the following command:
dotnet script exec <path to DLL>
I think this can be particularly useful for scripts repeated over and over, where contents rarely change. In the future we are planning to automatically cache a script like that, using sort of a hash of the script content. This is similar - to my knowledge - to what for example FAKE scripts do.
In both cases (executable and DLL publishing), once the script is published you can still pass arguments into it. For example:
dotnet script exec <path to DLL> -- <args>
Use external NuGet sources as CLI parameter π
For a long time, dotnet script supported using NuGet.config to configure NuGet package feeds - normally we just use the global one, but if you have one in the local folder, then that one is used. However, this doesn’t help the portability of scripts, as it might force you to drag along an extra file for no reason.
With this release, to alleviate the pain a bit, we added support for using NuGet sources as command line parameter - they will then be respected when restoring the inline Nuget packages (#r “nuget:⦔):
dotnet script foo.csx --sources http://my/package/source
You can also pass multiple sources:
dotnet script foo.csx --sources http://my/package/source --sources http://another/package/source
I would imagine this is going to be particularly useful in automation scenarios.
Better console output π
We added coloring to certain console output messages - for example dotnet script init or the new dotnet script publish. This should make it more readable and pleasant to work with.
Other π
One important thing to note with this release is that dotnet script is now .NET Core 2.1 only - we stopped cross compiling .NET Core 2.0 builds and we will not support that version anymore.
There is a wide array of other fixes, improvements and changes, including - for example - upgrading to latest Roslyn, 2.9.0.
I hope you enjoy this latest release. Aside from the usual team (Bernhard and me), David has been instrumental in getting this release out.
