NuGet Support

Overview

From the very early stage, CS-Script supported importing NuGet packages by the script being executed.

The initial integration of NuGet package manager (nuget.exe) was somewhat constrained. This is because .NET Framework and nuget.exe user experience were not fully consistent with the scripting paradigm as well as the .NET package importing workflow was heavily dependent on the IDE (Visual Studio).

With the arrival of .NET Core situation has changed. Package manager becomes an integral part of the SDK and no longer depends on any IDE. On top of this, the user experience has dramatically improved because of the heavy investment in the CLI for NuGet.

This created an opportunity for CS-SCript to realign its own NuGet support with one provided by .NET as a framework. Thus starting from v4.7.0 CS-Script implements new simplified NuGet support that is fully consistent with the package management provided by .NET:

Framework	.NET	CS-Script	CS-Script details
Adding package	dotnet add package <name>	Add //css_nuget <name> to the script	Will trigger restoring on script execution if any packages are added or removed.
Resoring packages	dotnet restore	css -nuget:restore <script>	Downloads package and extracts package assemblies.
Building/Running	dotnet build dotnet run	css <script>	Restores packages, if not done yet. References package assemblies and executes the application.

Roadmap

The new NuGet support was initially released as an option that needs to be enabled explicitly as by default CS-Script uses the legacy implementation:

css -config:set:LegacyNugetSupport=false

How does it work?

• LegacyNugetSupport=true
  In this mode, cs-script tries to explore the whole package dependency tree by itself. This algorithm is not ideal and may not work as expected depending on the dependency complexity. This is the algorithm that was the only option in the releases before v4.7.0

• LegacyNugetSupport=false
  In this mode, cs-script does not do any package handling. Instead, it calls dotnet restore for an on-fly project containing only nugep packages specified by the user in the script. Then it calls dotnet publish, analyses the output and collects all the locations of the resolved packages assemblies. And as a last step, it creates a new script file <your scriptfile>.nuget.cs next to the script being executed. This new file contains all the information about the package assemblies referenced by your script. Similar to the references in the .NET project file. The *.nuget.css file is processed by the script engine automatically. You do not need to do anything about it. This algorithm became available only in v4.7.0

In future releases LegacyNugetSupport will be disabled by default. And eventually, this option will be completely removed.

With the new NuGet support many CLI and //css_nuget options will have very little value so they will be depreciated. The final minimalistic set of options will become gradually available after v4.7.0:

• CLI: -nuget:restore
• Script directive: //css_nuget [-ver:<version>] [-restore:<dotnet restore arguments>] package