Skip to content

Be smarter about PackFolder on project references#181

Merged
kzu merged 1 commit intomainfrom
dev/transitive
May 26, 2022
Merged

Be smarter about PackFolder on project references#181
kzu merged 1 commit intomainfrom
dev/transitive

Conversation

@kzu
Copy link
Copy Markdown
Member

@kzu kzu commented May 26, 2022

Whenever we had PrivateAssets=all on a project reference (whether implicitly or explicitly), we used to unconditionally pass PackFolder=$(PackFolder) when resolving referenced content. This is correct whenever the calling project does indeed have a PackFolder, but not for packaging projects, since in that case, the packaging project itself doesn't have a value for that property (since it can pack any arbitrary content and has no primary output).

So we switch to the mechanism used already by the .NET SDK (and common targets) of using a metadata item with the full property assignment syntax. This means that if the metadata isn't present (which we now condition to the presence of a value for PackFolder), when calling GetPackageContents on the project reference, no value will be passed at all for that property, meaning whichever value is there already, will be propagated to the referencing project, which is exactly what we want in a packaging project scenario.

Fixes #139

@kzu kzu enabled auto-merge (rebase) May 26, 2022 18:21
@kzu kzu force-pushed the dev/transitive branch from 36d0943 to 401db24 Compare May 26, 2022 18:35
Whenever we had `PrivateAssets=all` on a project reference (whether implicitly or explicitly), we used to unconditionally pass `PackFolder=$(PackFolder)` when resolving referenced content. This is correct whenever the calling project does indeed have a `PackFolder`, but not for packaging projects, since in that case, the packaging project itself doesn't have a value for that property (since it can pack any arbitrary content and has no primary output).

So we switch to the mechanism used already by the .NET SDK (and common targets) of using a metadata item with the full property assignment syntax. This means that if the metadata isn't present (which we now condition to the presence of a value for `PackFolder`), when calling `GetPackageContents` on the project reference, no value will be passed at all for that property, meaning whichever value is there already, will be propagated to the referencing project, which is exactly what we want in a packaging project scenario.

Fixes #139
@kzu kzu force-pushed the dev/transitive branch from 401db24 to 591ac4b Compare May 26, 2022 18:43
@kzu kzu merged commit ca127ba into main May 26, 2022
@kzu kzu deleted the dev/transitive branch May 26, 2022 18:56
@devlooped devlooped locked and limited conversation to collaborators Nov 23, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Packaging project generates package improperly

1 participant