Better versioning of referenced NuGet packages

[UweKeim]

Behaviour

For months, I was successfully using

//css_nuget -force:3600 -ng:"-Source https://nuget.org/api/v2/" Microsoft.SqlServer.SqlManagementObjects

to include this package.

Unfortunately, they recently introduced a bug so I had to revert to a lower, working version. No problem:

//css_nuget -force:3600 -ver:150.18208.0 -ng:"-Source https://nuget.org/api/v2/" Microsoft.SqlServer.SqlManagementObjects

By adding -ver:150.18208.0 the correct version was downloaded into the local NuGet cache at

c:\ProgramData\CS-Script\nuget\Microsoft.SqlServer.SqlManagementObjects

Now when running my code, the error still persists.

Cause

After further investigation, I found out that the previously downloaded, newer but erroneous versions still were stored in "c:\ProgramData\CS-Script\nuget\Microsoft.SqlServer.SqlManagementObjects".

It seems that CS-Script downloads the correctly versioned package, but unfortunately after that download, another (random? heighest? ...?) version was actually imported into my script.

Thus, the error persisted.

Workaround

I deleted the whole "c:\ProgramData\CS-Script\nuget\Microsoft.SqlServer.SqlManagementObjects" folder, ran the script again, and now the issue was resolved.

My suggestion

Could you enhance the CS-Script "NuGet engine" to not only correctly download a specified version of a NuGet package but also include this specified version later on?

[oleg-shilo]

Hi Uwe,

In the original design I considered this to be a limitation (always use the highest version available) but not a defect. And, yes the expected work around was to clear packages cache. There is even a CLI command for clearing nuget packages.

However today, when the use of NuGet packages is so widely adopted this enhancement is in fact an essential functionality.

So I will implement it.

Interestingly enough. This will probably be the last progression feature for CS-Sharp as with the immanent release of .NET5 I will be depreciating this stream and shifting the emphasis on CS-Script.Core.

While it was always effort consuming to maintain both streams I had no choice as both streams had their user base. but with the release of ,NET5 it's only logical to support only one stream.

Interestingly enough, this evolutionary path exactly repeats what happens with .NET Framework and .NET Core.

---

BTW CS-Script.Core is immune to this problem as package management is completely delegated to dotnet.exe.

[UweKeim]

Should I simply switch to CS-Cscript.Core?

[oleg-shilo]

Fixed. The fix will be available in the very next release.

Should I simply switch to CS-Cscript.Core?
Uwe, so sorry but I have missed this question.

The simple answer YES, but be mindful of implications.

CS-Script.Core is an improvement over CS-Script in arguably all departments except one - external compiler (csc.exe) startup time.

With .NET Framework MS worked very hard to bring startup time down and did a really good job. On top of it they implemented a preloaded compiler service VBCSCompiler.exe, which stays action ready after the first compilation. Thus on practical level the compilation time is excellent. Even though this model comes with some challenges it is an excellent baseline. Thus CS-Script delivers a new script loading time on an "average" PC consistently under 1 second.

.NET Core from other hand has csc.exe startup time completely unaddressed. Thus on very same "average" PC it was ~7-10 seconds for all versions of .NET Core.

Note, this .NET Core startup penalty only takes place for the very first execution of the script. If the script is not modified and executed second time then (thanks to cs-script caching) this script starup time is consistently under ~200 msec regardless what .NET edition, version you are using.

Saying that the latest preview of .NET 5 has showed significant improvement. The "first execution" startup time now is ~5 seconds. And what is even more intriguing that the preheated compiler infrastructure (VBCSCompiler.exe file) is still there meaning that .NET Core will probably enable it at some stage.
BTW, CS-Script.Core preview for .NET 5 is already available on Choco and here.

Thus if "first execution" startup time is critical then you may want to delay the migration to CS-Script.Core until .NET 5 is out. Otherwise go for it.

[UweKeim]

Thanks a lot, Oleg!

In deed, startup speed is crucial in my current setup, since we are running hundreds of CS scripts during a setup build for our applications.

So probably I'll stick to non-Core just a little bit longer as of now ☺

[oleg-shilo]

I have implemented in Core version my own preheated compiler service just in case .NET 5 team gives up on the idea.

//css_compiler roslyn
using System;
using static dbg; // to use 'print' instead of 'dbg.print'
            
 void main()
 {
    print("Hello World!");
 }

It's lightning fast but not ideal. I do prefer MS has fixed the problem instead of me creating a poor man solution.

[oleg-shilo]

Done in release: https://github.com/oleg-shilo/cs-script/releases/tag/v3.30.4.0