Change the Windows dev versions leg to x86 #45362
Conversation
This gives us better coverage as it tests the case when the host architecture is different from the target architecture. I.e. here we are running on a win-x64 build with a win-x64 host (SDK) and target win-x86 (target).
ghost
added
|
I will pause this until #45347 is merged as the aspnetcore installer infrastructure changed significantly. |
@jkoritzinsky @mmitche I'm hitting the same issue that Jeremy noticed in aspnetcore. Here we are targeting win-x86 (target) but building with a win-x64 SDK (host) on a win-x64 OS (build). The host version of crossgen2 tries to get restored because that's what we need here to run crossgen. sdk/src/Installer/redist-installer/targets/GenerateLayout.targets Lines 83 to 84 in 30b271a Should we disable the crossgen invocation here as well temporarily when running inside the VMR? This probably works in source-build as the host and target is identical? |
|
I think we can/should disable it temporarily in the VMR until I get the crossgen work done. |
First of all, I hate this whole filtering model. It's super hacky and constantly causes issues. https://github.com/dotnet/source-build/issues/4047 tracks this. Here we need to also empty the `ProcessFrameworkReferences` target as it still runs as it has a Before/AfterTargets hook. Keep it running is causing issues when RuntimeIdentifier is set to a custom value even though the project should be excluded. Unblocks dotnet/sdk#45362
|
I have no idea why the patch doesn't apply |
|
The source-build failure will go away after #45749 is merged (newer Arcade bootstrap sdk). |
Co-authored-by: Premek Vysoky <[email protected]>
4 participants
This gives us better coverage as it tests the case when the host architecture is different from the target architecture. I.e. here we are running on a win-x64 build with a win-x64 host (SDK) and target win-x86 (target).
Unblocks using a unique OfficialBuildId that isn't available from the current msft build.