Last week, we released version 2.0 of dotnet-script. The latest release introduces support for .NET 10.0 and C# 14 and is available, as usually, through Github releases and on Nuget. You will need to have at least the .NET SDK 10.0.100 installed.
It is the first major release of dotnet-script since version 1.0, which was released back in 2020. At the same time, the breaking changes are minimal, and the revision is mostly driven by the careful application of semantic versioning principles.
Release overview π
.NET 10 LTS only came out on November 11, 2025, and we managed to push out the release on the 14th, which I think is quite cool - we wanted to make sure the scripting community can enjoy .NET 10.0 as quickly as possible.
Aside from supporting .NET 10.0 and C# 14, the release contains a usual set of bug fixes and small improvements, which are documented in the release notes. We still support and cross-compile for .NET 8.0 and .NET 9.0 - this is aligned with Microsoft’s lifetime policy for .NET versions.
The installation command is the same as always β you can get ahold of dotnet-script by running the dotnet tool installation:
dotnet tool install dotnet-script -g
For existing users, the update command is relevant:
dotnet tool update dotnet-script -g
If, after the upgrade, you are running into troubles with existing scripting due to script caching issues, make sure to try running the script with with -βno-cache flag.
What’s new π
The primary change in the new release is that starting with version 2.0.0, dotnet-script will use an isolated load context for loading assemblies. This means that when a script is compiled and executed, it will run in total isolation from the script host. In the old solution, the direct dependencies of the script were loaded into the same load context as dotnet-script itself. This can lead to assembly version conflicts if the script depends on a different version of an assembly than dotnet-script. This feature is particularly valuable when working with native dependencies - this was famously problematic in the old versions of dotnet-script. With the isolated load context, this problem is eliminated, as the script and its dependencies are loaded into a separate load context.
Script isolation was available as an opt-in in previous versions of dotnet-script, and you used to be able to enable it by passing the --isolated-load-context flag when executing the script. In the new version, the flag is gone - but a new flag called --disable-isolated-load-context has been added to allow opting out of the isolated load context if needed, and keep backwards compatibility.
There are some edge cases where we might want to opt out of this default - for instance if the script or any of its dependencies does a Assembly.Load.
Another new feature is the ability to pass the caching folder location via the command line argument --cache-path. This is equivalent to the existing DOTNET_SCRIPT_CACHE_LOCATION environment variable, but is far more convenient when running scripts in automation scenarios, especially in situations where swapping environment variables is not straightforward. This feature was contributed by psryland.
The consequence of this change is that there are some small breaking changes in the Dotnet.Script.Core APIs, so if you are using Dotnet.Script as a library, you will need to adapt.
Finally, we also finally test in CI on macOS arm64 architecture, which should give more confidence to users running dotnet-script on Apple Silicon.
Enjoy .NET scripting!
