Repository navigation
Pinned version in nuspec for .NET Core projects #3557
Agent suggestions
Public previewDescription
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.
Activity
github-actions commentedon Aug 29, 2026
🤖 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 (
FormatInNuGetSyntaxinVersionRange.fs) correctly turns an exact/pinned requirement into bracket syntax ([1.0.0]), so pinning works there.For SDK-style /
dotnet packprojects, however, the nuspec is generated by the .NET SDK's ownPackTask, 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 inpaket.dependencies/paket.lock). The SDK'sPackTaskthen 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 theVersionvalue 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 packinterprets thePackageReferenceVersionattribute compared to Paket's own (legacy) nuspec writer.Possible fix: Paket could optionally emit
Version="[1.0.0]"for the generatedPackageReferencewhen pinning is required, since NuGet restore accepts bracket syntax for a single resolved version equally well. However, this would change theVersionvalue 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.
Add this agentic workflow to your repo
To install this agentic workflow, run