Skip to content

List of artifacts that must be produced in Build Pass 2 and Build Pass 3, and why #4998

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

Open
mmitche opened this issue Apr 2, 2025 · 1 comment

Comments

@mmitche
Copy link
Member

mmitche commented Apr 2, 2025

Artifact Pass Why
Cross-OS DAC 2 The windows-based Cross-OS DACs must be published in the same package as their corresponding (Linux-based) runtimes to enable the DACs to be associated with their corresponding runtimes.
Windows SDK Bundle 3 The Windows SDK bundle builds on all windows verticals and depends on apphost msis from the alternate Windows verticals (i.e. on win-x64 needs win-x86 and win-arm64 apphost msis). Also depends on workload manifests msis. See #4998 (comment) for info on how the workload manifest info flows into the sdk bundle
VS.Redist.Common.Net.Core.SDK.MSBuildExtensions 2 Depends on hostfxr.dll from the win-x86 and win-arm64 verticals for the same reason as the above item.
VS.Redist.Common.Net.Core.SDK.VSTemplateLocator 2 Depends on hostfxr.dll from the win-x86 and win-arm64 verticals for the same reason as the above item.
Windows Hosting Bundle 2 Bundles .msi's from x64, x86, and arm64. Furthermore, the x64 components depend on x86 components due to WOW64; and the arm64 components depend on the x64 components via type forwarders.
Microsoft.AspNetCore.AzureAppServices.SiteExtension 2 Contains both x64 and x86 logging extension bits. Convenience package for aspnetcore customers.
Microsoft.AspNetCore.Server.IntegrationTesting.IIS 2 Contains native bits from x64, x86, and arm64. Convenience package for aspnetcore devs to do server integration testing locally
Workloads 2 See #4998 (comment)

Defined in VMR: https://github.com/dotnet/dotnet/blob/8f4e0bcafa4dda5268520ad4715721c72c7e45d3/repo-projects/dotnet.proj#L17-L30

Time for passes:

Pass Cost (signed)
1 4.25-4.5hrs
2 2 hrs
3 30-35mins
@akoeplinger
Copy link
Member

akoeplinger commented Apr 2, 2025

For workloads there are essentially three pieces:

  1. Workload manifest .msi's
  2. Workload pack .msi's
  3. VS insertion .zip's

They get produced by the same build step in BP2 since we need to grab all of the nuget packages referenced in the workload manifests (e.g. browser/ios/android runtime packs, AOT compilers, build tasks) so it needs to run after the verticals that produce them.

It creates an .msi which wraps the content of each nuget package. This is because on Windows the dotnet sdk is installed in ProgramFiles so we need to elevate when installing a workload there (unless you do a .zip file-based install, then those are not used).

Those MIS assets then also go into two places:

  • The VS insertion .zip so that the VS installer can also offer it (which confusingly is also called workloads but is separate from the dotnet workloads concept).
  • Another set up of NuGet packages that we publish on nuget.org.

The workload manifest .msi's are then chained into the SDK bundle in BP3. It needs to be the exact same .msi that goes into the VS insertion .zip.

None of this is relevant for Linux/macOS since we only do the file-based workload install there, even if you install the sdk from .pkg/.deb.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

3 participants