You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
Defined in VMR: https://github.com/dotnet/dotnet/blob/8f4e0bcafa4dda5268520ad4715721c72c7e45d3/repo-projects/dotnet.proj#L17-L30
Time for passes:
The text was updated successfully, but these errors were encountered: