Closed schauerte closed 3 years ago
I just realized, that (of course), any TypeProvider that is generated from the current template also cannot use dotnet pack
with the current dotnet sdk version.
I came to the conclusion, that nothing should be changed here. I just hope, the fix for NuGet/Home#9786 will eventually make it into the 3.1 LTS version (before 5.1 arrives).
See also fsprojects/Paket#3897 for reference.
It just bothers me, that this whole ecosystem (.NET Framework/dotnetcore, TypeProvider SDK/SQLProvider, NuGeT/Paket) leads to such a bad experience for beginners (at least on Linux). Everything I try seems broken because of some glitch on some more or less unrelated dependency.
Executing the build script fails, when using dotnet sdk 3.1.403 but succeeds with dotnet sdk 3.1.302 (as specified in the workflow file). I was able to trace down the cause to a NuGet/Home#9786 (more details on this may be found in Slack).
The issue seems to be solved for .net5, but may never be solved for 3.1. In my opinion it would be beneficial when the build could succeed on the current LTS version of the dotnet sdk. To archive this, I've added a version check to disable package creation when an unsupported version is used.
This change could easily be reverted, when the underlying issue is fixed (or the version gets outdated).
Maybe there are better workarounds. Things I've considered:
dotnet paket pack
instead ofdotnet pack
- would require transforming the nuspec into paket.template and seems not very welcomed (see Slack & https://twitter.com/BlythMeister/status/1222501608191340545)