fix: make NuGetizer self-pack robust so build/ assets always land correctly#726
Merged
Conversation
…build/ not content/ The v1.4.8 regression (triggered by syncs for PackageId defaults + the duplicate NuGet pack import workaround) caused the project's *.props, *.targets and related build assets to end up under content/ and contentFiles/ in the published .nupkg instead of build/. Root cause: - 'dotnet pack' sets GeneratePackageOnBuild=true, which skipped the old delegation condition in NuGetizer.Tasks.Pack.targets. - The forced <Import> of real NuGet.Build.Tasks.Pack.targets (late in Directory.Build.targets) made the SDK pack path win. - Without explicit location metadata, inference + SDK defaults treated the files as content. Robust fix: * Explicit PackagePath="build\..." (and buildMultiTargeting for the special ones) on the build support files. PackagePath takes precedence in both NuGetizer's AssignPackagePath and the SDK pack. * Late <Target Name="Pack"> delegator in Directory.targets (after the SDK pack import) so PackFolder=build projects (including NuGetizer itself) force the NuGetize=true path. * Condition the manual pack targets import on 'NuGetize' != 'true'. * Loosen the small Pack delegator conditions so the delegation is not tied to GeneratePackageOnBuild=='false'. This ensures correct layout even if the pack driver or Directory.Build changes again.
Member
Author
|
🧪 Details on Ubuntu 24.04.4 LTS🧪 Details on Microsoft Windows 10.0.26100from dotnet-retest v1.0.0 on .NET 10.0.9 with 💜 by @devlooped |
kzu
added a commit
to devlooped/oss
that referenced
this pull request
Jun 24, 2026
…jects (#39) ### Problem Projects using NuGetizer + `PackFolder=build` (the standard way to author MSBuild/ tool packages) would get their assets incorrectly placed under `content/` + `contentFiles/` when packed via `dotnet pack`. This is the same root cause that affected the nugetizer 1.4.8 release. ### Root cause - The shared `Directory.Build.targets` always imported the real `NuGet.Build.Tasks.Pack.targets`. - "dotnet pack" flows did not reliably go through the `NuGetize=true` path. - Result: SDK pack defaults won instead of NuGetizer's `PackFolder` inference. ### Fix * Condition the import of the real pack targets: `And '$(NuGetize)' != 'true'`. When a project opts into NuGetizer via `NuGetize`, don't pull in the conflicting SDK pack targets. * Add a late `<Target Name="Pack">` delegator (after the pack import) that, for any project with `PackFolder=build` or `buildTransitive`, re-invokes MSBuild with `NuGetize=true`. This guarantees the correct packaging logic runs. The delegator is declared late in the file so it takes precedence. See also the consuming change in devlooped/nugetizer#726
This was referenced Jun 25, 2026
This was referenced Jun 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
NuGetizer 1.4.8 (and builds after the PackageId / duplicate-import sync work) was publishing a broken package: its own
build/*.props,build/*.targets,NuGetizer.*, etc. ended up undercontent/+contentFiles/any/...instead ofbuild/(andbuildMultiTargeting/).This broke downstream users because the MSBuild targets/props were not discovered.
Root cause
GeneratePackageOnBuild=true) skipped the old delegation condition.NuGet.Build.Tasks.Pack.targets(added to workaround SDK PackageId defaults) made the SDK pack path win forNuGetizer.Tasks.DefaultPackFolder=contentforNone/Contentitems.Fix (robust)
PackagePath="build\..."(with overrides for thebuildMultiTargetingcopies) on all the build support files.PackagePathis honored by both NuGetizer and the SDK pack.Packtarget delegator inDirectory.targets(after the SDK pack import) that forces theNuGetize=truepath forPackFolder=buildprojects.NuGetize != 'true'.GeneratePackageOnBuild=='false'.These changes make the layout of NuGetizer's own assets independent of how
dotnet pack/ IDE pack / Directory.Build changes are made in the future.Fixes the 1.4.8 layout regression reported for the published package.