When loading a script package via the preprocessor directive, the loading fails because the behavior of the in process nuget installer changed. Before 0.34.1 it allowed to install nuget packages with prelease versions without explicitly adding the &prerelease statement.
The current implementation in 0.34.1 will result in a misleading output message rather stating the fact that it was not possible to find a release version with the given version number.
// works!
#load "nuget:?package=My.Cool.Script.Package&version=12.2.1.171"
// does not work, console just throws No scripts found in NuGet package My.Cool.Script.Package
#load "nuget:?package=My.Cool.Script.Package&version=12.3.1-rc0001.174"
// works!
#load "nuget:?package=My.Cool.Script.Package&version=12.2.1.171"
// works!
// or
// Unable to find release package in specified version.
#load "nuget:?package=My.Cool.Script.Package&version=12.3.1-rc0001.174"
0.34.1
64
Windows
@cake-build/cake-team opinion time! Should we
a) go back to initial behavior, and install prerelease package even though prerelease=true is not specified in directive?
Or
b) Throw an exception explaining that users must set prerelease=true in directive in order to install a pre-release package.
IIRC, option a) is in conflict on how nuget.exe works. But e.g. <PackageReference> works as in option a).
@cake-build/cake-team I vote for a, think there's already an open issue around this.
I tend to agree with @devlead here. If the version is explicitly specified the assumption is the user wants that specific version. Obviously, if the version isn鈥檛 specified, only the latest non pre-release version should be resolved, unless they add the prerelease flag.
I also agree with @devlead and @gep13: If a version was explicitly specified we should honor it.
If we chose option a, wouldn't prerelease become useless?
@Jericho
If we chose option a, wouldn't
prereleasebecome useless?
No, this is the exact behaviour prior to 0.34.x, prerelease is only useful if a version is not specified. But if a version is specified, then the prerelease flag is useless.
:tada: This issue has been resolved in version v1.0.0 :tada:
The release is available on:
Your GitReleaseManager bot :package::rocket:
Most helpful comment
I tend to agree with @devlead here. If the version is explicitly specified the assumption is the user wants that specific version. Obviously, if the version isn鈥檛 specified, only the latest non pre-release version should be resolved, unless they add the prerelease flag.