I'm using Nuget 4.3.0.4406 to pack an assembly with version 5.2.29.181212.8244-RC but I get
2018-12-12T08:44:02.8053309Z ##[error]The nuget command failed with
exit code(1) and error('5.2.29.181212.8244-RC' is not a valid version
string. Parameter name: value)
The versioning is NOT semver compliant but Nuget puts on restrictions and it's not clear which..? Does this mean Nuget not just supports SemVer but enforces it? I found this but I'm not sure what they mean with the SpecialVersion?
Basically I just want x.y.z.[date+buildid](-rc) where x.y.z are tied to a specification version so it can not be ommitted (we don't own that versioning).
Update
9.9.9.1812129999-rc works but 9.9.9.18121299999-rc and 9.9.9.9812129999-rc don't, where is this specified? (it's a numeric size limitation not a string length)
Taken from the NuGet Package Versioning Reference on Microsoft Docs:
With NuGet 4.3.0+ and Visual Studio 2017 version 15.3+, NuGet supports Semantic Versioning 2.0.0.
Certain semantics of SemVer v2.0.0 are not supported in older clients. NuGet considers a package version to be SemVer v2.0.0 specific if either of the following statements is true:
The pre-release label is dot-separated, for example, 1.0.0-alpha.1
The version has build-metadata, for example, 1.0.0+githash
For nuget.org, a package is defined as a SemVer v2.0.0 package if either of the following statements is true:
The package's own version is SemVer v2.0.0 compliant but not SemVer v1.0.0 compliant, as defined above.
Any of the package's dependency version ranges has a minimum or maximum version that is SemVer v2.0.0 compliant but not SemVer v1.0.0 compliant, defined above; for example, [1.0.0-alpha.1, ).
Of course you can find the Semmantic Versioning Specification at semver.org. I think you're especially interested in spec-item10:
Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.
Your version would become something like x.y.z(-rc)+[date+buildid]
Related
I have declared the following package reference
<PackageReference Include="Abc.Defg" Version="9.9.5.*" />
With the desire that it should pick exactly a version 9.9.5 followed by the highest revision number it can find eg. 9.9.5.1234
Any package that doesn't start with 9.9.5. should be invalid eg. 9.9.6.0 or 9.9.4.0
I am getting the following message when I call nuget CLI command nuget restore but fail to understand how exactly to fix the warning and still get my desired result
WARNING: NU1604: Project dependency Abc.Defg does not contain an inclusive lower bound. Include a lower bound in the dependency version to ensure consistent restore results.
FYI, in case it makes a difference, the package version numer isn't declared directly as shown above but instead it is declared in a Directory.Build.props as a Property.
<MyVersion>9.9.5.*</MyVersion>
Which is than used as the following
<PackageReference Include="Abc.Defg" Version="$(MyVersion)" />
Is it possible to fix this with only one version number or do I need to change it to something like this
[9.9.5,9.9.6)
Which, if I am correct, translates to include 9.9.5.0 (0 can be omitted) and everything up to exclusively 9.9.6, so from 9.9.5.0 till 9.9.5.65534 should be valid.
The 9.9.5.* version extends the version range not just up, but down as well.
Lower version numbers that match this wildcard version constraint may not have the required "Abc.Defg" dependency.
The lower version number may need to be set to a version that covers this dependency, perhaps ...
(9.9.5.4, 9.9.5.*)
My goal is to deploy NuGet packages (to in-house Nuget server) that auto-increment the version based on date and last Rev, and include a -beta tag.
I am using VSTS to build and package using cake, with a build number format of $(BuildDefinitionName)_2.0.$(Date:yyMMdd)$(Rev:.r).
I have a .nuspec manifest file that specifies: $version$, and a NuGet Packager as such:
This works great. But now, I want to have the option of a NuGet packager that produces a package that is tagged as beta, and therefor show in VS NuGet Package Manager as pre-release. I can do this if I hard code the version number with "-beta" appended in the NuGet Packager:
But how can I include the -beta tag AND the the build number? I think I need to include a variable in NuGet Arguments that will return $(BuildDefinitionName)_2.0.$(Date:yyMMdd)$(Rev:.r) plus "-beta", but I'm not sure how.
I tried creating a variable (under the Variables tab) with the Build Number Format as the value, then referencing the variable in NuGet Arguments (-Version theVariable), but received as error that the variable is not supported.
I may be going about this all wrong, however my searches have not turned up any hints on how to auto-increment versions from the date, and include a -beta tag.
NuGet Packager with version using build number, adding -beta
I could reproduce your scenario on my side. In my opinion, Nuget pack task with build number doesn't support character or numbers. You may check this task:
case "byBuildNumber":
tl.debug("Getting version number from build number")
if(tl.getVariable("SYSTEM_HOSTTYPE") === "release")
{
tl.setResult(tl.TaskResult.Failed, tl.loc("Error_AutomaticallyVersionReleases"));
return;
}
let buildNumber: string = tl.getVariable("BUILD_BUILDNUMBER");
tl.debug(`Build number: ${buildNumber}`);
let versionRegex = /\d+\.\d+\.\d+(?:\.\d+)?/;
let versionMatches = buildNumber.match(versionRegex);
if (!versionMatches)
{
tl.setResult(tl.TaskResult.Failed, tl.loc("Error_NoVersionFoundInBuildNumber"));
return;
}
if (versionMatches.length > 1)
{
tl.warning(tl.loc("Warning_MoreThanOneVersionInBuildNumber"))
}
version = versionMatches[0];
break;
That is the reason why the field $(BuildDefinitionName) and beta could not appear in our package version when we use them in our build number.
If we specify the nuget version in the nuget arguments, but this argument could not parsing predefined variables, like $(Rev:.r).
The limitations of these two situations have caused your current issue.
The workaround to resolve this issue, is using nuget custom task with parameter -version $(Build.BuildNumber) and move the field $(BuildDefinitionName) from our Build number format, otherwise, we still receive the error the version is invalid.
So, you nuget custom looks like:
And the Build number format:
Now, you can see it works fine:
Note:
You said you using VSTS to build and package using cake, but the images you posted shows that you are using NuGet Packagertask in TFS 2015. If you are sure using TFS 2015, I am afraid above workaround will not work for you. Because the custom nuget task is not support for TFS 2015.
Hope this helps.
What is meaning of the * wildcard in the nuget 4.6.2
<PackageReference Include="Autofac">
<Version>*</Version>
</PackageReference>
The PackageReference documentation in turn refers to the package versioning documentation, which includes:
When using the PackageReference format, NuGet also supports using a wildcard notation, *, for Major, Minor, Patch, and pre-release suffix parts of the number. Wildcards are not supported with the packages.config format.
The documentation is a little unclear when it comes to pre-releases:
Pre-release versions are not included when resolving version ranges. Pre-release versions are included when using a wildcard (*). The version range [1.0,2.0], for example, does not include 2.0-beta, but the wildcard notation 2.0-* does.
My experience is that it will pick up pre-releases when the wildcard is after a dash, but not before.
As a worked example, at the time of writing, xunit has version 2.3.1 and 2.4.0-beta.1.build3958. Here's the results I get:
Version attribute Version installed
* 2.3.1
2.* 2.3.1
2.4.* Error
2-* 2.0.0
2.4.0-* 2.4.0-beta.1.build3958
The * is a wild card, as you specified. This means the package you're building needs some version of Autofac.
Here are sample version numbers for Nuget packages:
1.1.9-version3
1.1.8-version3
1.1.7-version3
Here are the channel rules for a Channel titled "Version3":
Version Range: [1.1.1-2.0.0]
Tag: version3
I can't make it any simpler - why are these packages not matching the channel rule? Even removing the version range doesn't seem to make any difference.
As per the Nuget versioning syntax, a range is defined by a comma-separator, the hyphen is for defining the pre-release tag.
Your version range should be [1.1.1,2.0.0]. The tag should be correct.
When building a nuget package with folder lib\i-made-this-up\, nuget Pack will output the following message:
The folder 'i-made-this-up' under 'lib' is not recognized
as a valid framework name or a supported culture identifier.
Folder lib\net40-wpf\ does not output this message so apparently it is a valid framework name. My questions is: how is net40-wpf defined? I expected it to be on this page but it isn't:
https://docs.nuget.org/create/enforced-package-conventions
Do I miss something? Or is there a better source of documentation?
You have the main documentation link for the NuGet target frameworks:
https://docs.nuget.org/create/enforced-package-conventions
Unfortunately it is out of date and is missing newer target frameworks that NuGet supports.
A few more target frameworks are mentioned in the following blog post:
http://blog.nuget.org/20150729/Introducing-nuget-uwp.html
Currently the best place is the NuGet source code. For NuGet v2 the known target frameworks are defined in the VersionUtility class:
https://github.com/NuGet/NuGet2/blob/2.8.6/src/Core/Utility/VersionUtility.cs
For NuGet 3 the list of target frameworks is defined in the FrameworkConstants class:
https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Frameworks/FrameworkConstants.cs
NuGet 3 also has a set of runtime identifiers which are defined in a NuGet package so it is extensible.