sdk
sdk copied to clipboard
dotnet
Merge the net10 dotnet/runtime and dotnet/aspnetcore codeflows
@marcpopMSFT I attempted to merge the net10 dotnet/runtime and dotnet/aspnetcore codeflows, manually updating some dependencies for 10.0 and adding 10.0 templates. The build succeeded, but many tests failed. The failure information is as follows:
System.TypeLoadException : Could not load type 'System.Runtime.InteropServices.MemoryMarshal' from assembly 'System.Runtime, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Could you look at this?
VMR leg failed with the following (@dotnet/product-construction )
- Test failures in Ubuntu
- CompareAssemblyVersions and CompareFileContents
- Windows leg failed hte build
- D:\a_work\1\vmr\repo-projects\Directory.Build.targets(476,5): error : Repository asset manifest files don't exist. [D:\a_work\1\vmr\repo-projects\fsharp.proj]
Source build leg failed with a prebuilt for net10 (@dotnet/source-build-internal ) __w/1/s/.packages/microsoft.dotnet.arcade.sdk/10.0.0-beta.24430.1/tools/SourceBuild/AfterSourceBuild.proj(81,5): error : 1 new pre-builts discovered! Detailed usage report can be found at /__w/1/s/artifacts/sb/prebuilt-report/baseline-comparison.xml. Microsoft.NETCore.App.Crossgen2.linux-x64.10.0.0-alpha.1.24431.5
System.TypeLoadException : Could not load type 'System.Runtime.InteropServices.MemoryMarshal' from assembly 'System.Runtime, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Could you look at this?
@dotnet/dnr-codeflow any ideas on this one? Seems to be the common failure across most of the tests I scanned through.
@v-wuzhai were you going to start on the changes for GenerateBundledVersions.targets for the known framework references and known runtime packs (amongst others)? I think that change can be prepped in parallel to this: I believe you did this last time here: https://github.com/dotnet/installer/pull/17432
@v-wuzhai were you going to start on the changes for GenerateBundledVersions.targets for the known framework references and known runtime packs (amongst others)? I think that change can be prepped in parallel to this: I believe you did this last time here: dotnet/installer#17432
The change was made with https://github.com/dotnet/sdk/pull/42969
It is now causing 2nd-stage failures in VMR: https://dev.azure.com/dnceng/internal/_build/results?buildId=2531460&view=logs&j=9f4c4083-9864-5575-dedd-fb296084d8e2&t=15f0c853-f021-5549-d93c-f01428803354
/vmr/eng/tools/BinaryToolKit/BinaryToolKit.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Ref with version (= 9.0.0-preview.7.24405.7)
/vmr/eng/tools/BinaryToolKit/BinaryToolKit.csproj : error NU1102: - Found 8 version(s) in /tmp/tmp.xLJpd9ApwU [ Nearest version: 9.0.0-rc.1.24414.5 ]
/vmr/eng/tools/BinaryToolKit/BinaryToolKit.csproj : error NU1102: - Found 0 version(s) in /vmr/.dotnet/library-packs
@v-wuzhai were you going to start on the changes for GenerateBundledVersions.targets for the known framework references and known runtime packs (amongst others)? I think that change can be prepped in parallel to this: I believe you did this last time here: dotnet/installer#17432
The change was made with #42969
It is now causing 2nd-stage failures in VMR: https://dev.azure.com/dnceng/internal/_build/results?buildId=2531460&view=logs&j=9f4c4083-9864-5575-dedd-fb296084d8e2&t=15f0c853-f021-5549-d93c-f01428803354
/vmr/eng/tools/BinaryToolKit/BinaryToolKit.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Ref with version (= 9.0.0-preview.7.24405.7) /vmr/eng/tools/BinaryToolKit/BinaryToolKit.csproj : error NU1102: - Found 8 version(s) in /tmp/tmp.xLJpd9ApwU [ Nearest version: 9.0.0-rc.1.24414.5 ] /vmr/eng/tools/BinaryToolKit/BinaryToolKit.csproj : error NU1102: - Found 0 version(s) in /vmr/.dotnet/library-packs
Should the hardcoded value be changed to a property that can be overridden by source-build so that it can pick up the version from previous artifacts?
@v-wuzhai were you going to start on the changes for GenerateBundledVersions.targets for the known framework references and known runtime packs (amongst others)? I think that change can be prepped in parallel to this: I believe you did this last time here: dotnet/installer#17432
The change was made with #42969 It is now causing 2nd-stage failures in VMR: https://dev.azure.com/dnceng/internal/_build/results?buildId=2531460&view=logs&j=9f4c4083-9864-5575-dedd-fb296084d8e2&t=15f0c853-f021-5549-d93c-f01428803354
/vmr/eng/tools/BinaryToolKit/BinaryToolKit.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Ref with version (= 9.0.0-preview.7.24405.7) /vmr/eng/tools/BinaryToolKit/BinaryToolKit.csproj : error NU1102: - Found 8 version(s) in /tmp/tmp.xLJpd9ApwU [ Nearest version: 9.0.0-rc.1.24414.5 ] /vmr/eng/tools/BinaryToolKit/BinaryToolKit.csproj : error NU1102: - Found 0 version(s) in /vmr/.dotnet/library-packsShould the hardcoded value be changed to a property that can be overridden by source-build so that it can pick up the version from previous artifacts?
Yes, that is my idea for a fix, but I need to confirm that this is the case, in a local repro (building atm).
@v-wuzhai were you going to start on the changes for GenerateBundledVersions.targets for the known framework references and known runtime packs (amongst others)? I think that change can be prepped in parallel to this: I believe you did this last time here: dotnet/installer#17432
The change was made with #42969 It is now causing 2nd-stage failures in VMR: https://dev.azure.com/dnceng/internal/_build/results?buildId=2531460&view=logs&j=9f4c4083-9864-5575-dedd-fb296084d8e2&t=15f0c853-f021-5549-d93c-f01428803354
/vmr/eng/tools/BinaryToolKit/BinaryToolKit.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Ref with version (= 9.0.0-preview.7.24405.7) /vmr/eng/tools/BinaryToolKit/BinaryToolKit.csproj : error NU1102: - Found 8 version(s) in /tmp/tmp.xLJpd9ApwU [ Nearest version: 9.0.0-rc.1.24414.5 ] /vmr/eng/tools/BinaryToolKit/BinaryToolKit.csproj : error NU1102: - Found 0 version(s) in /vmr/.dotnet/library-packsShould the hardcoded value be changed to a property that can be overridden by source-build so that it can pick up the version from previous artifacts?
Yes, that is my idea for a fix, but I need to confirm that this is the case, in a local repro (building atm).
Wouldn't that solution break the build when runtime starts producing 10-versioned App.Ref package? All projects targeting 9.0 would need to be updated to target 10.0, or we'd need a 9.0 SBRP package - but only after 9.0 RTM.
Wouldn't that solution break the build when runtime starts producing 10-versioned App.Ref package? All projects targeting 9.0 would need to be updated to target 10.0, or we'd need a 9.0 SBRP package - but only after 9.0 RTM.
Correct, Once 9.0 GAs, we would add the 9.0 targeting pack to SBRP and this issue goes away.
Interesting, I have a special rule for mentions but just adding me as a reviewer just goes in my clutter folder. So I had no idea that work had already been done. I think getting this working is the next step. Still need someone from runtime to look at the MemoryMarshal exception in the tests.
System.TypeLoadException : Could not load type 'System.Runtime.InteropServices.MemoryMarshal' from assembly 'System.Runtime, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.Could you look at this?
@dotnet/dnr-codeflow any ideas on this one? Seems to be the common failure across most of the tests I scanned through.
@dotnet/runtime-infrastructure Could you take a look at the failures here?
My attempts to replicate the VMR build here are not working. Could someone link to instructions on how to diagnose this?
My attempts to replicate the VMR build here are not working. Could someone link to instructions on how to diagnose this?
One "easy" way is to utilize this devcontainer - https://github.com/dotnet/sdk/blob/main/.devcontainer/vmr/README.md
Why would aspnetcore fail exclusively to windows?
DynamicClientProxy.cs(12,5): error IL3050: Using member 'System.Dynamic.DynamicObject.DynamicObject()' which has 'RequiresDynamicCodeAttribute'
@joeloff part of the VMR win-x64 failure appears to be wix related Which leg?
@agocke I thought you were going to look at the MemoryMarshal which was in the regular SDK build. Looking at latest results, the SDK build appears mostly clean now with the newer updates. The source build leg is hitting the MemoryMarshal issue that the SDK tests were previously hitting.
We do need someone looking at the VMR failures as well though those are test failures and an aspnet build failure that Steve points to above. Not sure how to run the VMR tests accurately to fix those.
@joeloff part of the VMR win-x64 failure appears to be wix related Which leg?
VMR Vertical Build Windows_x64 - windowsdesktopbuild
For the SDK build, we have 4 container test failures and a blazor failure @lewing @baronfel
\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(495,5): error NETSDK1112: The runtime pack for Microsoft.NETCore.App.Runtime.Mono.browser-wasm was not downloaded.
System.InvalidOperationException : The registry was not loaded after 5 retries. Spawn registry attempt #1 failed, Xunit.Sdk.XunitException: Expected command to pass but it did not.
VMR Vertical Build Windows_x64 - windowsdesktopbuild
Ahh, it has more than one error. When you click on the build, it takes you to the aspnet failure which you linked above but if you scroll, you get a wix failure. I didn't realize they would have multiple errors that far apart in the log.
https://dev.azure.com/dnceng-public/public/_build/results?buildId=806152&view=logs&j=9050e078-31bf-5111-d8ec-8b6fa95caf9c&t=523d8a07-ca4d-5c7a-367a-d86c5fc4038b&l=3789
\sb\package-cache\microsoft.dotnet.build.tasks.installers\10.0.0-beta.24430.1\build\wix\wix.targets(354,5): error : Exec FAILED: exit code 103 (attempt 5/5) [D:\a\_work\1\vmr\src\windowsdesktop\src\windowsdesktop\src\bundle\Microsoft.WindowsDesktop.App.Bundle.bundleproj]
Ahh, it has more than one error. When you click on the build, it takes you to the aspnet failure which you linked above but if you scroll, you get a wix failure. I didn't realize they would have multiple errors that far apart in the log.
In a lot of cases the build will not stop when one repo or another has an error.
Looks like the failure happens when trying to link the desktop bundle, and that's why there already are retries
https://github.com/dotnet/arcade/blob/344004446883e2d577d21a9844f997215964279a/src/Microsoft.DotNet.Build.Tasks.Installers/build/wix/wix.targets#L348C5-L359C28
For the SDK build, we have 4 container test failures and a blazor failure @lewing @baronfel
\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(495,5): error NETSDK1112: The runtime pack for Microsoft.NETCore.App.Runtime.Mono.browser-wasm was not downloaded.System.InvalidOperationException : The registry was not loaded after 5 retries. Spawn registry attempt #1 failed, Xunit.Sdk.XunitException: Expected command to pass but it did not.
given that is this includes the version switch from 9 to 10 I imagine the workload update logic is confused
Checking on status:
- @lewing what's the fix for the browser-wasm failure if it is a migration from 9 to 10 causing it
- @baronfel I assume the container tests are the known failure and can be ignored if it comes to that. Should we add the test disable commit to this PR perhaps?
- @MichaelSimons I saw that https://github.com/dotnet/source-build/issues/4607 was marked as compelted. Any changes needed in this PR?
- @agocke any luck with the remaining VMR failures? Were you looking into those or someone else?
@MichaelSimons I saw that https://github.com/dotnet/source-build/issues/4607 was marked as compelted. Any changes needed in this PR?
That issue is orthogonal to the failure here.
The Linux VMR failures look like version issues that aren't specific to runtime.
The Windows VMR issue, after a little digging, looks a bit strange... I wonder if this is an overload resolution change. @333fred Can you take a look? The specific call it seems to be complaining about is Expression.Lambda(typeof(Func<object?>), methodCallExpression!) and the signature it's picking is System.Linq.Expressions.Expression.Lambda(Expression, params ParameterExpression[]), which doesn't look right.