Wrong versions of NuGet libraries are getting referenced

[UweKeim]

Since I'm using the new cs-script.cli dotnet tool in more projects, I discover that sometimes the wrong NuGet packages are being references (reason yet unknown to me).

I'm using css -config:set:LegacyNugetSupport=false to switch to the new NuGet mechanism.

This both refers to NuGet packages on private NuGet sources as well as the public ones on nuget.org.

In some of my projects, the wrong package versions are pull.

For example:

In my file do-build.cs there is a reference to my package ZetaShortPaths. As of writing this, the newest version is 1.0.23.

This version also resides in the folder "C:\Users\ukeim.nuget\packages\zetashortpaths":

C:\>dir C:\Users\ukeim\.nuget\packages\zetashortpaths
 Datenträger in Laufwerk C: ist System
 Volumeseriennummer: 7438-5E9C

 Verzeichnis von C:\Users\ukeim\.nuget\packages\zetashortpaths

28.03.2023  21:26    <DIR>          .
28.03.2023  21:27    <DIR>          ..
28.03.2023  21:26    <DIR>          1.0.23
               0 Datei(en),              0 Bytes
               3 Verzeichnis(se), 742.416.154.624 Bytes frei

and

C:\>dir C:\Users\ukeim\.nuget\packages\zetashortpaths\1.0.23\
 Datenträger in Laufwerk C: ist System
 Volumeseriennummer: 7438-5E9C

 Verzeichnis von C:\Users\ukeim\.nuget\packages\zetashortpaths\1.0.23

28.03.2023  21:26    <DIR>          .
28.03.2023  21:26    <DIR>          ..
28.03.2023  21:26               182 .nupkg.metadata
27.03.2023  15:30            11.511 .signature.p7s
14.01.2022  12:46            10.595 icon.png
28.03.2023  21:26    <DIR>          lib
14.01.2022  12:46               724 README.md
28.03.2023  21:26            42.403 zetashortpaths.1.0.23.nupkg
28.03.2023  21:26                88 zetashortpaths.1.0.23.nupkg.sha512
28.03.2023  00:29             1.024 zetashortpaths.nuspec
               7 Datei(en),         66.527 Bytes
               3 Verzeichnis(se), 742.415.822.848 Bytes frei

So everything working as expected so far.

Now when running

css /dbg do-build.cs

a new file do-build.cs.nuget.cs is being created with this content:

// packages: morelinq, Newtonsoft.Json, RestSharp, SharpZipLib, ZetaDeployer.RuntimeUploader, ZetaShortPaths
//css_ref C:\Users\ukeim\.nuget\packages\sharpziplib\1.4.2\lib\net6.0\ICSharpCode.SharpZipLib.dll
//css_ref C:\Users\ukeim\.nuget\packages\jetbrains.annotations\2022.3.1\lib\netstandard2.0\JetBrains.Annotations.dll
//css_ref C:\Users\ukeim\.nuget\packages\microsoft.win32.systemevents\6.0.0\lib\net6.0\Microsoft.Win32.SystemEvents.dll
//css_ref C:\Users\ukeim\.nuget\packages\morelinq\3.4.1\lib\net6.0\MoreLinq.dll
//css_ref C:\Users\ukeim\.nuget\packages\newtonsoft.json\13.0.3\lib\net6.0\Newtonsoft.Json.dll
//css_ref C:\Users\ukeim\.nuget\packages\restsharp\109.0.1\lib\net7.0\RestSharp.dll
//css_ref C:\Users\ukeim\.nuget\packages\system.configuration.configurationmanager\6.0.0\lib\net6.0\System.Configuration.ConfigurationManager.dll
//css_ref C:\Users\ukeim\.nuget\packages\system.drawing.common\6.0.0\lib\net6.0\System.Drawing.Common.dll
//css_ref C:\Users\ukeim\.nuget\packages\system.security.cryptography.protecteddata\6.0.0\lib\net6.0\System.Security.Cryptography.ProtectedData.dll
//css_ref C:\Users\ukeim\.nuget\packages\system.security.permissions\6.0.0\lib\net6.0\System.Security.Permissions.dll
//css_ref C:\Users\ukeim\.nuget\packages\system.windows.extensions\6.0.0\lib\net6.0\System.Windows.Extensions.dll
//css_ref C:\Users\ukeim\.nuget\packages\zetadeployer.runtimeuploader\1.0.10\lib\net7.0\ZetaDeployer.RuntimeUploader.dll
//css_ref C:\Users\ukeim\.nuget\packages\zetashortpaths\1.0.20\lib\netstandard2.0\ZetaShortPaths.dll

As you can see the very last line refers to version 1.0.20 in the C:\Users\ukeim\.nuget\packages\zetashortpaths\ folder. As seen above, no such version exists in that folder.

Same is for other packages, e.g. ZetaDeployer.RuntimeUploader in version 1.0.10 where in reality the version 1.0.17 is present in the Nuget folder.

Probably other libraries are wrong, too.

Naturally my script does not run then, since the packages cannot be imported thus my code cannot call the classes in the (not loaded) NuGet libraries.

What did I try

I've tried to call these commands:

dotnet nuget locals all --clear
rmdir C:\ProgramData\CS-Script\nuget /S /Q

and then deleted the file do-build.cs.nuget.cs.

Then I ran css /dbg do-build.cs again.

Now the above do-build.cs.nuget.cs file suddenly looks like this:

// packages: morelinq, Newtonsoft.Json, RestSharp, SharpZipLib, ZetaDeployer.RuntimeUploader, ZetaShortPaths
//css_ref C:\Users\ukeim\.nuget\packages\sharpziplib\1.4.2\lib\net6.0\ICSharpCode.SharpZipLib.dll
//css_ref C:\Users\ukeim\.nuget\packages\jetbrains.annotations\2022.3.1\lib\netstandard2.0\JetBrains.Annotations.dll
//css_ref C:\Users\ukeim\.nuget\packages\morelinq\3.4.1\lib\net6.0\MoreLinq.dll
//css_ref C:\Users\ukeim\.nuget\packages\newtonsoft.json\13.0.3\lib\net6.0\Newtonsoft.Json.dll
//css_ref C:\Users\ukeim\.nuget\packages\restsharp\109.0.1\lib\net7.0\RestSharp.dll
//css_ref C:\Users\ukeim\.nuget\packages\zetadeployer.runtimeuploader\1.0.18\lib\net7.0\ZetaDeployer.RuntimeUploader.dll
//css_ref C:\Users\ukeim\.nuget\packages\zetashortpaths\1.0.23\lib\netstandard2.0\ZetaShortPaths.dll

And suddenly my script runs correctly.

(It has way fewer //css_ref lines, too 🤔)

Still, some point later in the future, it somehow does not run again and the file do-build.cs.nuget.cs looks again like the first version above.

I absolutely have no clue where he gets the old versions from and why it changes sometimes.

Is it possible that the NuGet probing mechanism somehow sees older references to NuGet packages inside other NuGet packages but still restores newer ones?

My question

Do you have any clue what might happen here, and how I could resolve this?

[oleg-shilo]

Hi Uwe, I may have some ideas about what is happening there:

With the new NuGet support, cs-script has completely delegated the decision about resolving the package's dependencies to the dotnet. Thus when you add a package to the script this actions are triggered at the script first time execution:

• A class lib VS project is created at the random location
• All requested packages from the script added to the VS project
• dotnet publish executed so dotnet resolves all packages and aggregates them in the published folder
• c-script analyzes UserProfile/.nuget/packages folder and locates all assemblies from published folder. The result is written in the *.cs.nuget.cs.
• cs-script references all located assemblies when compiles the script.

Thus if you ever see and dll in the *.cs.nuget.cs file, then indeed it existed at the time of analysis.

Reevaluation of the packages only happens if you add or remove a package to/from the script or execute css -nuget:restore script.cs. Or brutally delete *.cs.nuget.cs file, which is the same as -nuget:restore.

Thus in your case, you most likely dotnet nuget locals all --clear removed the wrong version of the package. And removing *.cs.nuget.cs file triggered the reevaluation of the nuget packages by cs-script.

I absolutely have no clue where he gets the old versions from and why it changes sometimes.

This is something that I have no explanation for. Unless .dotnet is doing something funny with nuget cache.

rmdir C:\ProgramData\CS-Script\nuget /S /Q

You don't need to do this. Since new NuGet algorithm lets dotnet to do the stuff. This dir is no longer used

[UweKeim]

Thanks, Oleg,

Does this imply that new versions of NuGet packages are not being detected, once the *.cs.nuget.cs file was written?

I think I'll try to do a css -nuget:restore every time before calling my actual script.

[oleg-shilo]

Does this imply that new versions of NuGet packages are not being detected, once the *.cs.nuget.cs file was written?

Correct. This is consistent with the VS experience. packages are only updated upon user request.