Skip to content

Use x64 emscripten version for downloading workload packs #49463

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

Merged
merged 1 commit into from
Jun 18, 2025

Conversation

mmitche
Copy link
Member

@mmitche mmitche commented Jun 18, 2025

The internal version won't work for stable builds. Unfortunely, there's not a non-arch or emscripten version specific package to use. Nothing else from emsdk ships that is built in an earlier pass. Not ideal. If we create a non-shipping package that has stable versioning, publishing will reject it because won't go to an isolated feed. So far, repos have avoided having shipping sentinel packages.

The internal version won't work for stable builds. Unfortunely, there's not a non-arch or emscripten version specific package to use. Nothing else from emsdk ships that is built in an earlier pass. Not ideal. If we create a non-shipping package that has stable versioning, publishing will reject it because won't go to an isolated feed. So far, repos have avoided having shipping sentinel packages.
@Copilot Copilot AI review requested due to automatic review settings June 18, 2025 00:06
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

This PR updates the workload pack download configuration to use the x64 Emscripten version for stable builds.

  • Updates the PackageDownload version in workloads.csproj to reference the new MicrosoftNETRuntimeEmscripten3156Cachewinx64Version property.
  • Adds the new version property in eng/Versions.props.
  • Adjusts dependency definitions in eng/Version.Details.xml by adding a new dependency for the x64 package and removing the SourceBuild attribute from the internal dependency.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File Description
src/Workloads/VSInsertion/workloads.csproj Updated package and downloaded workload pack references to use the x64 Emscripten version.
eng/Versions.props Introduced new version property for the x64 Emscripten package.
eng/Version.Details.xml Added new dependency entry for the x64 package and removed the SourceBuild from the internal dependency.
Comments suppressed due to low confidence (3)

src/Workloads/VSInsertion/workloads.csproj:99

  • The new PackageDownload reference correctly switches the version property. Please verify that this change aligns with the intended behavior for stable builds and that no downstream components rely on the previous internal version.
    <PackageDownload Include="@(EmsdkWorkloadPacksToDownload)" Version="[$(MicrosoftNETRuntimeEmscripten3156Cachewinx64Version)]" />

src/Workloads/VSInsertion/workloads.csproj:105

  • Ensure that the path update using the new x64 version property is supported by all relevant tooling, as this change alters the lookup for downloaded packages.
      <DownloadedWorkloadPacks Include="$(NuGetPackageRoot)\%(EmsdkWorkloadPacksToDownload.Identity)\$(MicrosoftNETRuntimeEmscripten3156Cachewinx64Version)\*.nupkg" />

eng/Version.Details.xml:71

  • The new dependency entry lacks a SourceBuild attribute compared to the internal dependency entry. Verify that omitting this attribute is intentional and conforms with the design for stable/shipping packages.
    <Dependency Name="Microsoft.NET.Runtime.Emscripten.3.1.56.Cache.win-x64" Version="10.0.0-preview.6.25316.103">

@mmitche mmitche merged commit 87febc1 into dotnet:main Jun 18, 2025
28 of 31 checks passed
@mmitche
Copy link
Member Author

mmitche commented Jun 18, 2025

Rate limit issue

@mmitche
Copy link
Member Author

mmitche commented Jun 18, 2025

/backport to release/10.0.1xx-preview6

Copy link
Contributor

Started backporting to release/10.0.1xx-preview6: https://github.com/dotnet/sdk/actions/runs/15734634193

Copy link
Contributor

@mmitche backporting to "release/10.0.1xx-preview6" failed, the patch most likely resulted in conflicts:

$ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch

Applying: Use x64 emscripten version for downloading workload packs The internal version won't work for stable builds. Unfortunely, there's not a non-arch or emscripten version specific package to use. Nothing else from emsdk ships that is built in an earlier pass. Not ideal. If we create a non-shipping package that has stable versioning, publishing will reject it because won't go to an isolated feed. So far, repos have avoided having shipping sentinel packages.
Using index info to reconstruct a base tree...
M	eng/Version.Details.xml
M	eng/Versions.props
Falling back to patching base and 3-way merge...
Auto-merging eng/Versions.props
CONFLICT (content): Merge conflict in eng/Versions.props
Auto-merging eng/Version.Details.xml
CONFLICT (content): Merge conflict in eng/Version.Details.xml
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Patch failed at 0001 Use x64 emscripten version for downloading workload packs The internal version won't work for stable builds. Unfortunely, there's not a non-arch or emscripten version specific package to use. Nothing else from emsdk ships that is built in an earlier pass. Not ideal. If we create a non-shipping package that has stable versioning, publishing will reject it because won't go to an isolated feed. So far, repos have avoided having shipping sentinel packages.
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants