MinVerBuildMetadata not used in nupkg version

[adamralph]

MinVerBuildMetadata not used in nupkg version

[adamralph]

@blairconrad build metadata gets built into appears in the version in the nuspec inside the package. It does not appear in the filename. This is standard .NET SDK (dotnet pack) behaviour.

[adamralph]

Reason being: build metadata really is just metadata. It's not part of the version. If it was included in the filename, you wouldn't be able to use the filesystem as a package source, since you'd have duplicate packages.

[blairconrad]

Thanks for the explanation.

Ironically, this lack of metadata in the filename is exactly what's keeping me from using the filesystem as a package source. I want to subscribe to 2 different nupkgs, each of which were built as one-commit-past-develop. The nupkgs' filenames collide now. I can manually rename the nupkgs after they are produced, but I didn't expect to have to.

As a side note, I'd've expected diagnostic-level output to output its calculated AssemblyVersion, FileVersion, PackageVersion, and Version (and I guess PackageFilenameVersion or whatever, since it's distinct.)

[blairconrad]

GitVersion had been putting part of the branch name in the generated filenames, and I realized that we'd lose that when switching to MinVer, but I had (erroneously) thought that the metadata would allow me to work around that.

[adamralph]

Ironically, this lack of metadata in the filename is exactly what's keeping me from using the filesystem as a package source. I want to subscribe to 2 different nupkgs, each of which were built as one-commit-past-develop. The nupkgs' filenames collide now. I can manually rename the nupkgs after they are produced, but I didn't expect to have to.

Can you describe more about this use case? I assume they were built on different branches?

As a side note, I'd've expected diagnostic-level output to output its calculated AssemblyVersion, FileVersion, PackageVersion, and Version (and I guess PackageFilenameVersion or whatever, since it's distinct.)

👍 sounds reasonable. Raised #147.

[blairconrad]

Can you describe more about this use case? I assume they were built on different branches?

Sure. It's niche.
I'm benchmarking. BenchmarkDotNet lets me run benchmarks against various nuget versions. Sometimes I want to benchmark and compare a couple of changes, maybe each of them implemented by one commit off "develop". (Each on their own branch, as you say.)

I used to be able to build pack on each branch, and out would pop a uniquely-named nupkg, which I'd subscribe to. Now, with the only potential differentiator in the filename being the number of commits since last tag, I'm getting collisions.

[adamralph]

OK. FWIW, I think I'm going to release another beta which will expose the pre-release part of the version as something like MinVerPreRelease, which means you can override the versioning and stitch it together yourself, e.g.

<Target Name="MyTarget" AfterTargets="MinVer" Condition="'$(BRANCH)' != ''">
  <PropertyGroup>
    <PackageVersion>$(MinVerMajor).$(MinVerMinor).$(MinVerPatch)-$(MinVerPrerelease).$(BRANCH)+$(MinVerBuildMetadata)</PackageVersion>
    <Version>$(PackageVersion)</Version>
  </PropertyGroup>
</Target>

I may even consider adding some kind of new input variable which allows you to inject a pre-release prefix and/or suffix into MinVer itself. 💭

[adamralph]

@blairconrad I guess this question is answered, but keep an eye on the new beta for things that might help your use case.

[blairconrad]

Indeed. Thanks for your time!