-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Allow container targets to be loaded in more scenarios, even if the targets will be skipped #47693
Conversation
…nvocations since we handle that now
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. |
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. |
Per offline conversation, can / should we include integration tests for this scenario? |
yes, will be doing this today |
Ok, test added! |
src/Tests/Microsoft.NET.Build.Containers.IntegrationTests/EndToEndTests.cs
Outdated
Show resolved
Hide resolved
LGTM |
ae63da7
to
5c03933
Compare
Description
When publishing a solution with
dotnet publish /t:PublishContainer
when the solution contains at least one multi-targeted project, container publish fails because thePublishContainer
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