Sdk: Unable to use <Version> in .csproj with --version-suffix during dotnet pack

[WolfyUK]

Steps to reproduce

• dotnet new classlib
• Edit .csproj and add <Version>1.0.0-*</Version> (see dotnet-pack command)
• dotnet restore
• dotnet pack --version-suffix XXX

Expected behavior

Successfully created package 'Project.1.0.0-XXX.nupkg

Actual behavior

Invalid NuGet version string: '1.0.0-*'

The --version-suffix value only seems to work when the <Version> element is not present in the .csproj file. In this case, the expected package is generated.

Environment data

dotnet --info output:
.NET Command Line Tools (1.0.0-rc4-004771)

Product Information:
Version: 1.0.0-rc4-004771
Commit SHA-1 hash: d881d45b75

Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\1.0.0-rc4-004771

[WolfyUK]

If the <Version> element contains just 1.0.0, without the trailing hyphen and asterisk then the --version-suffix value seems to be ignored completely during dotnet pack.

[WolfyUK]

Workaround

dotnet pack --help shows the following for the --version-suffix argument:

Defines the value for the $(VersionSuffix) property in the project.

Thus:

• Edit .csproj and set <Version>1.0.0$(VersionSuffix)</Version>
• dotnet pack --version-suffix -XXX

[dasMulli]

@WolfyUK the idea is that you don't specify <Version> but <VersionPrefix>1.0.0</…> and the SDK will then derive the Version from how these properties are set.

[dasMulli]

For reference, the logic is defined here.

[WolfyUK]

Thanks for the info - this works perfectly. The documentation could do with updating to reflect this.

[conficient]

There is a problem with this approach. As soon as a dev goes into package properties, they see "Package Version: [ 1.0.0 ]" and if they edit this, the $(VersionSuffix) is dropped.

[dasMulli]

@conficient The VS properties are implemented in https://github.com/dotnet/project-system so you could open an issue there.

There is https://github.com/dotnet/project-system/issues/3151 already which is sort of related.