Skip to content

[repo-assist] Fix #3603: paket pack reads Package-prefixed metadata from SDK-style csproj - #4417

Open
github-actions[bot] wants to merge 1 commit into
masterfrom
repo-assist/fix-issue-3603-package-release-notes-90f305c8d24e4d55
Open

[repo-assist] Fix #3603: paket pack reads Package-prefixed metadata from SDK-style csproj#4417
github-actions[bot] wants to merge 1 commit into
masterfrom
repo-assist/fix-issue-3603-package-release-notes-90f305c8d24e4d55

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

🤖 This PR was created by Repo Assist, an automated AI assistant.

Closes #3603

Root cause

ProjectFile.GetTemplateMetadata() (used by paket pack to read NuGet metadata directly from .csproj files) only read the legacy plain MSBuild property names: ReleaseNotes, ProjectUrl, IconUrl, LicenseExpression, LicenseUrl, RequireLicenseAcceptance, Tags.

SDK-style (new-format) .csproj files conventionally set the Package-prefixed equivalents instead: PackageReleaseNotes, PackageProjectUrl, PackageIconUrl, PackageLicenseExpression, PackageLicenseUrl, PackageRequireLicenseAcceptance, PackageTags. As a result, paket pack silently produced packages missing release notes (and other metadata) for SDK-style projects using these properties.

This is also inconsistent with Paket's own Paket.Restore.targets, which already maps PackageReleaseNotesReleaseNotes when invoking PackTask.

Fix

Added propOrPackage/propMapOrPackage helpers in GetTemplateMetadata() that try the plain property name first, then fall back to the Package-prefixed name. This preserves existing behavior for legacy-style projects (plain name always wins if present) while fixing the gap for SDK-style projects.

Trade-offs

Only extended fields with an established Package-prefixed MSBuild convention (matching what Paket.Restore.targets already expects). Fields like Title, Owners, Summary, Readme, Language, Icon, Copyright, and repository info were left unchanged since they don't have an equivalent SDK convention.

Test Status

  • Build: ✅ dotnet build succeeds with no new warnings/errors.
  • Targeted tests: ✅ Added two new tests in tests/Paket.Tests/Packaging/PackageProcessSpecs.fs verifying the fallback and that plain properties still take precedence — both pass.
  • Full PackagingProcess test module: 5/6 pass; the one pre-existing failure (Loading assembly metadata works, a version-string mismatch) is unrelated to this change and reproduces on master as well.

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

…perties

SDK-style csproj files conventionally use Package-prefixed MSBuild
properties (PackageReleaseNotes, PackageProjectUrl, PackageIconUrl,
PackageLicenseExpression, PackageLicenseUrl,
PackageRequireLicenseAcceptance, PackageTags) instead of the legacy
plain property names. GetTemplateMetadata() previously only read the
plain names, so 'paket pack' silently dropped this metadata for
SDK-style projects.

Added propOrPackage/propMapOrPackage helpers that try the plain
property name first (preserving legacy behavior) and fall back to the
Package-prefixed name. This matches the convention already used by
Paket.Restore.targets, which maps PackageReleaseNotes to ReleaseNotes
when invoking PackTask.

Added regression tests verifying the fallback works and that a plain
property still takes precedence when both are present.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@dsyme
dsyme marked this pull request as ready for review September 1, 2026 15:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Pack with type project should find release notes in new csproj

0 participants