Read VersionPrefix instead of Version

[seangwright]

This is a nice little tool, thanks for making it.

I was wondering if it would be possible to read <VersionPrefix> instead of <Version> as an option?

When I run dotnet pack I use the --version-suffix flag to set the prerelease / ci value of my version to $(Build_BuildNumber) and that means I need my csproj to store <VersionPrefix> instead of <Version> so the two values can be merged.

Ex)
csproj

 <PropertyGroup>
    <VersionPrefix>1.0.0</VersionPrefix>
</PropertyGroup>

with the following
dotnet pack App/App.csproj -c Release --version-suffix ci-$(Build_BuildNumber) --no-build --no-restore

Produces something like
App.1.0.0-ci-231423.nupkg

Version vs VersionPrefix vs VersionSuffix

[conficient]

Sorry, I'm not completely clear on how you'd use the environment variable in pack? From your example it seems to work as you intended already?

[seangwright]

Your Powershell script pulls the <Version> value out of the *proj.cs file.

I'm using <VersionPrefix> in my .csproj file, not <Version>.

This allows me to perform a build 1 time but pack multiple times with or without a <VersionSuffix>.

My <VersionSuffix> (or lack of one) indicates the quality of the package.

When my package starts out it has a -ci-XXXXXX suffix which indicates it's not a fully validated release of the package.

After going through my release pipeline the suffix is finally removed and a fully validated release package of the original build is pushed to Azure artifacts.

[conficient]

Sorry @seangwright still not clear on how you'd use the environment variable. Even so, I've amend the code to extract VersionPrefix and VersionSuffix from the project and put them in variables. Version 1.14 is now up.

[seangwright]

Ah, I guess I didn't really explain that part.

I'm using the Promote package to Release View extension in my release pipeline.

Each stage in my pipeline works with the same build pipeline artifact and the above extension needs to be able to grab an existing Nuget package in my Azure Artifacts feed from a specific View and then promote that package without editing it to a new View (@Local -> @beta).

The one issue is that you have to know the exact version of the package you want to promote.

My package versions are generated by a combination of the <VersionPrefix> in the .csproj suffixed with -ci-$(Build.BuildNumber). The suffix is available to me in the release pipeline for that specific build artifact for all stages but the <VersionPrefix> needs to be extracted from the .csproj coming from the build artifact.

What I end up with is a dynamic package version expression that defines the package to promote between views which I provide to the above extension.

$(build.custom.versionPrefix)-ci-$(Build.BuildNumber)

where build.custom.versionPrefix comes from your extension.

So thanks! I got to remove a big blob of custom powershell from my release pipeline and use your extension in its place.

[seangwright]

@conficient

Just as a heads up - I tested this update out this morning and it doesn't quite work.

The issue specifically is here

if ($version -eq "")
{
    # FAIL
    Throw "No usable version found"
}

<Version> and <VersionPrefix> perform the same duty with <VersionPrefix> having less control over the final version number compared to <Version>.

You would never have both defined but you might have <VersionPrefix> and <VersionSuffix>

The most likely scenarios are

1. <Version> only
2. <VersionPrefix> only
3. <VersionPrefix> and <VersionSuffix>

The way this is currently running you have to have a <Version> which overrides <VersionPrefix> and <VersionSuffix>.

I believe the logic would need to be something like

• if Version != '', set Version and return
• if VersionPrefix == '', throw Error
• if VersionSuffix != '', set VersionSuffix and return

Thoughts?

I'll add back my custom powershell script in the meantime.

Thanks!