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

[release/9.0] [browser] Fix processing of satellite assemblies from referenced assembly during publish #107398

Merged
merged 12 commits into from
Sep 12, 2024

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Sep 5, 2024

Backport of #106696 to release/9.0

/cc @maraf

Customer Impact

  • Customer reported
  • Found internally

This PR fixes publishing satellite assemblies in (Blazor) WebAssembly apps in two scenarios

  • when there is a <Reference Include="A.dll" /> with satellite assemblies,
  • when there is a <ProjectReference Include="A.csproj" /> with satellite assemblies.

Regression

  • Yes
  • No

The first scenario (reference) was reported by customer in #105937. After investigation it turned out it is not a regression, and this scenario was never working in Blazor WebAssembly apps.

The second scenario (project reference) was discovered during investigation and is in fact regression from #90436. It wasn't well covered with tests, as it manifests only when wasm-tools workload is installed and publish is running for project with a project reference with satellite assemblies.

Testing

The PR adds automated tests for both reference and project reference with satellite assemblies and doing publish with workload installed.

Risk

Low. Affected scenarios are covered with automatic tests. One potential unknown is that the PR enables satellite assembly probing in nested build, which may result in slower publish, but the underlaying MSBuild task (ResolveAssemblyReference) searches only top-level directory where each reference lives, which should not be a significant IO overhead.

@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Sep 5, 2024
@maraf maraf added arch-wasm WebAssembly architecture area-Build-mono os-browser Browser variant of arch-wasm and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Sep 5, 2024
@maraf maraf added this to the 9.0.0 milestone Sep 5, 2024
@maraf maraf self-assigned this Sep 5, 2024
Copy link
Contributor

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

@lewing lewing added the Servicing-consider Issue for next servicing release review label Sep 9, 2024
@lewing
Copy link
Member

lewing commented Sep 10, 2024

/ba-g failure is known and tracked

@lewing lewing added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Sep 10, 2024
@lewing
Copy link
Member

lewing commented Sep 10, 2024

/ba-g failures are known and tracked

Copy link
Member

@jeffschwMSFT jeffschwMSFT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

approved. we can merge when ready

@jeffschwMSFT jeffschwMSFT merged commit 24cd94c into release/9.0 Sep 12, 2024
10 checks passed
@maraf maraf deleted the backport/pr-106696-to-release/9.0 branch September 13, 2024 11:36
@github-actions github-actions bot locked and limited conversation to collaborators Oct 14, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-wasm WebAssembly architecture area-Build-mono os-browser Browser variant of arch-wasm Servicing-approved Approved for servicing release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants