Skip to content

Allow container targets to be loaded in more scenarios, even if the targets will be skipped #47693

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

baronfel
Copy link
Member

@baronfel baronfel commented Mar 18, 2025

Description

When publishing a solution with dotnet publish /t:PublishContainer when the solution contains at least one multi-targeted project, container publish fails because the PublishContainer target isn't loaded when targeting multiple TFMs.

This is an artifact of our original single-TFM nature that isn't apparent when publishing single projects and really only shows up when publishing at the solution level. We need to enable this target to be called in a multi-TFM context even if the target itself doesn't support multi-TFM publishing. This is safe because the SDK itself blocks multi-TFM publishing of a project (you get NETSDK1129 errors), we just need to not block libraries and other non-exe-projects from being able to be built at the solution level.

Impact

Almost completely blocking for any solution-level container publish - the only workaround is making a stub PublishContainer Target in the library projects, which is very gnarly and likely will shoot us in the foot later on.

Risk

Medium - this fixes library-style projects from breaking in this scenario, but without the NETSDK1129 error you'd end up in a weird state. We probably need to go back and add multi-TFM detection and processing inside the PublishContainer target itself to be safest, but that's an even larger change.

Testing

  • manual testing against a reproducing setup
  • added to the existing automated tests for solution-level publish

@ghost
Copy link

ghost commented Mar 18, 2025

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

@ghost ghost added the untriaged Request triage from a team member label Mar 18, 2025
@ghost
Copy link

ghost commented Mar 18, 2025

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

@baronfel baronfel added the Area-Containers Related to dotnet SDK containers functionality label Mar 18, 2025
@baronfel baronfel requested a review from a team March 18, 2025 15:37
@MattKotsenas
Copy link
Member

Per offline conversation, can / should we include integration tests for this scenario?

@baronfel
Copy link
Member Author

Per offline conversation, can / should we include integration tests for this scenario?

yes, will be doing this today

@baronfel
Copy link
Member Author

Ok, test added!

@baronfel baronfel changed the title allow container targets to be loaded directly for multi-rid publish invocations since we handle that now Allow container targets to be loaded in more scenarios, even if the targets will be skipped Mar 19, 2025
@surayya-MS
Copy link
Member

LGTM

@baronfel baronfel force-pushed the do-not-break-classlibs-when-multi-tfm-publishing-containers branch from ae63da7 to 5c03933 Compare March 19, 2025 17:43
@rbhanda rbhanda added this to the 8.0.16 milestone Mar 20, 2025
@Forgind Forgind removed untriaged Request triage from a team member Branch Lockdown labels Apr 2, 2025
@baronfel baronfel merged commit e3e0f6b into dotnet:release/8.0.4xx Apr 3, 2025
19 of 22 checks passed
@baronfel baronfel deleted the do-not-break-classlibs-when-multi-tfm-publishing-containers branch April 3, 2025 16:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Containers Related to dotnet SDK containers functionality Servicing-approved
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants