Pinned version in nuspec for .NET Core projects

[Uriel6575]

I'm not sure it's related to paket, but I'll try.

The thing is that I want to keep pinned version constraint from paket.dependencies when running dotnet pack.
If I use standard PackageReference approach I just need to specify version as [1.0.0] and then it will get to nuspec just like that.
But If I use paket, then no matter how I specify pinned constraint in dependencies file (just 1.0, = 1.0 or even [1.0]) the version in nuspec is still just 1.0. Which means to NuGet >= 1.0.

[github-actions]

🤖 This is an automated response from Repo Assist.

Thanks for the report — I dug into this.

Root cause: for the classic (non-SDK) project format, Paket's own nuspec generation (FormatInNuGetSyntax in VersionRange.fs) correctly turns an exact/pinned requirement into bracket syntax ([1.0.0]), so pinning works there.

For SDK-style / dotnet pack projects, however, the nuspec is generated by the .NET SDK's own PackTask, not by Paket. Paket's restore step (RestoreProcess.fs) writes the resolved package version into the generated <PackageReference><Version>1.0.0</Version></PackageReference> as a plain version string (matching what you'd write in paket.dependencies/paket.lock). The SDK's PackTask then converts that literal into NuGet's default minimum-inclusive range (>= 1.0.0) when authoring the dependency entry in the nuspec — it only preserves an exact pin if the Version value itself uses bracket syntax ([1.0.0]).

So this isn't a bug in Paket's version-range formatting logic; it's a difference in how dotnet pack interprets the PackageReference Version attribute compared to Paket's own (legacy) nuspec writer.

Possible fix: Paket could optionally emit Version="[1.0.0]" for the generated PackageReference when pinning is required, since NuGet restore accepts bracket syntax for a single resolved version equally well. However, this would change the Version value used for both restore and pack for every SDK-style project, so it needs a maintainer decision (e.g., a new pinning option) rather than a silent behavior change — I'd recommend discussing whether this should be opt-in before implementing.

I'll leave this open for maintainer input on the preferred approach; happy to implement once there's agreement on the design.

Generated by 🌈 Repo Assist, see workflow run. Learn more.
_{Comment /repo-assist to run again}

_{Add this agentic workflow to your repo}

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@ae8d551f07c7ed7619f8c58c7bb4c3ac89395d38