Skip to content
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

[DO NOT MERGE] Restore ability for users to consume the containers package easily #43794

Merged

Conversation

surayya-MS
Copy link
Member

@surayya-MS surayya-MS commented Sep 30, 2024

Description

Users that try to use the NuGet package for containers with an SDK that already ships Containers support hit two main blockers that are difficult to work around for users that are not extremely skilled in MSBuild. We should enable users on 8.0 SDKs to use updated 8.0 packages for containerization to satisfy cases where users cannot update SDKs to the latest features.

This PR fixes two things:

  1. When the user references the Microsoft.NET.Build.Containers package and sets _ContainersTargetsDir (or it is set inside the package), a warning appears when running dotnet publish -t:PublishContainer that says:
warning MSB4011: "{path}\.nuget\packages\microsoft.net.build.containers\8.0.403\build\Microsoft.NET.Build.Containers.targets" 
cannot be imported again. It was already imported at 
"{path to the project that we try to publish}.csproj.nuget.g.targets (4,5)". This is most likely a build authoring error. 
This subsequent import will be ignored.
  1. Silencing the warning
The Microsoft.NET.Build.Containers NuGet package is explicitly referenced but the current SDK can natively publish the project as a container. Consider removing the package reference to Microsoft.NET.Build.Containers because it is no longer needed.

Solution:

  1. Importing .targets from internal build only when _ContainersTargetsDir was not set.
  2. Adding code to the warning (Chet's commit + test fix)

Customer Impact

Without this, users cannot easily switch to using the Containers package - they get impossible to suppress warnings (which are errors if WarningsAsErrors is enabled) and some of the SDK logic will be pinned in a way that the Containers package cannot overwrite due to MSBuild semantics, so the experience of the user will be mixed.

Regression

Yes, we regressed the 'pluggability' aspect of the user experience in 8.0.200.

Risk

Low - we have excellent test coverage here and have added to it to check the semantics here.

@surayya-MS surayya-MS requested a review from a team as a code owner September 30, 2024 16:45
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Containers Related to dotnet SDK containers functionality untriaged Request triage from a team member labels Sep 30, 2024
@surayya-MS surayya-MS changed the title Multi arch containers prerequisites [DO NOT MERGE] Multi arch containers prerequisites Sep 30, 2024
@baronfel baronfel changed the title [DO NOT MERGE] Multi arch containers prerequisites [DO NOT MERGE] Restore ability for users to consume the containers package easily Oct 3, 2024
@baronfel
Copy link
Member

baronfel commented Oct 4, 2024

Approved over email, waiting for confirmation that branches are open.

@baronfel
Copy link
Member

baronfel commented Oct 4, 2024

Confirmed!

@baronfel baronfel merged commit 29991fa into dotnet:release/8.0.4xx Oct 4, 2024
17 checks passed
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 DO NOT MERGE Servicing-approved untriaged Request triage from a team member
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants