sdk icon indicating copy to clipboard operation
sdk copied to clipboard

[main] Update dependencies from dotnet/runtime

Open dotnet-maestro[bot] opened this issue 1 year ago • 26 comments

This pull request updates the following dependencies

Coherency Updates

The following updates ensure that dependencies with a CoherentParentDependency attribute were produced in a build used as input to the parent dependency's build. See Dependency Description Format

  • Coherency Updates:
    • Microsoft.NET.Workload.Emscripten.Current.Manifest-10.0.100.Transport: from 10.0.0-alpha.1.24504.3 to 10.0.0-alpha.1.24514.2 (parent: Microsoft.NETCore.App.Runtime.win-x64)
    • Microsoft.SourceBuild.Intermediate.emsdk: from 10.0.0-alpha.1.24504.3 to 10.0.0-alpha.1.24514.2 (parent: Microsoft.NETCore.App.Runtime.win-x64)

From https://github.com/dotnet/runtime

  • Subscription: cedddd63-79f5-4e7e-6d46-08dc434c4948
  • Build: 20241021.2
  • Date Produced: October 21, 2024 4:04:33 PM UTC
  • Commit: 1e5bae2e56180897c95ac3f9adaa5609d14d20b3
  • Branch: refs/heads/main

dotnet-maestro[bot] avatar Oct 09 '24 12:10 dotnet-maestro[bot]

Notification for subscribed users from https://github.com/dotnet/runtime:

@dotnet/dnr-codeflow

Action requested: Please take a look at this failing automated dependency-flow pull request's checks; failures may be related to changes which originated in your repo.

  • This pull request contains changes from your source repo (https://github.com/dotnet/runtime) and seems to have failed checks in this PR. Please take a peek at the failures and comment if they seem relevant to your changes.
  • If you're being tagged in this comment it is due to an entry in the related Maestro Subscription of the Build Asset Registry. If you feel this entry has added your GitHub login or your GitHub team in error, please update the subscription to reflect this.
  • For more details, please read the Arcade Darc documentation

dotnet-maestro[bot] avatar Oct 09 '24 12:10 dotnet-maestro[bot]

Same as https://github.com/dotnet/sdk/pull/44012

nagilson avatar Oct 09 '24 18:10 nagilson

@maraf @jeromelaban please take a look at the blazor test failures

lewing avatar Oct 09 '24 23:10 lewing

The remaining failure (dotnet-sdk-public-ci (Build FullFramework: windows (x64))) is

C:\h\w\B0EC0997\t\dotnetSdkTests\zbey5ghz.0ec\.nuget\packages\microsoft.net.sdk.webassembly.pack\10.0.0-alpha.1.24509.15\build\Microsoft.NET.Sdk.WebAssembly.Browser.targets(366,5): error : System.IO.FileNotFoundException: Could not load file or assembly 'System.Text.Json, Version=8.0.0.5, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified. [C:\h\w\B0EC0997\t\dotnetSdkTests\zbey5ghz.0ec\Build_Service---C624F51F\blazorwasm\blazorwasm.csproj]
        C:\h\w\B0EC0997\t\dotnetSdkTests\zbey5ghz.0ec\.nuget\packages\microsoft.net.sdk.webassembly.pack\10.0.0-alpha.1.24509.15\build\Microsoft.NET.Sdk.WebAssembly.Browser.targets(366,5): error : File name: 'System.Text.Json, Version=8.0.0.5, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' [C:\h\w\B0EC0997\t\dotnetSdkTests\zbey5ghz.0ec\Build_Service---C624F51F\blazorwasm\blazorwasm.csproj]
        C:\h\w\B0EC0997\t\dotnetSdkTests\zbey5ghz.0ec\.nuget\packages\microsoft.net.sdk.webassembly.pack\10.0.0-alpha.1.24509.15\build\Microsoft.NET.Sdk.WebAssembly.Browser.targets(366,5): error :    at Microsoft.NET.Sdk.WebAssembly.GenerateWasmBootJson.WriteBootJson(Stream output, String entryAssemblyName) [C:\h\w\B0EC0997\t\dotnetSdkTests\zbey5ghz.0ec\Build_Service---C624F51F\blazorwasm\blazorwasm.csproj]
        C:\h\w\B0EC0997\t\dotnetSdkTests\zbey5ghz.0ec\.nuget\packages\microsoft.net.sdk.webassembly.pack\10.0.0-alpha.1.24509.15\build\Microsoft.NET.Sdk.WebAssembly.Browser.targets(366,5): error :    at Microsoft.NET.Sdk.WebAssembly.GenerateWasmBootJson.Execute() [C:\h\w\B0EC0997\t\dotnetSdkTests\zbey5ghz.0ec\Build_Service---C624F51F\blazorwasm\blazorwasm.csproj]
        C:\h\w\B0EC0997\t\dotnetSdkTests\zbey5ghz.0ec\.nuget\packages\microsoft.net.sdk.webassembly.pack\10.0.0-alpha.1.24509.15\build\Microsoft.NET.Sdk.WebAssembly.Browser.targets(366,5): error :  [C:\h\w\B0EC0997\t\dotnetSdkTests\zbey5ghz.0ec\Build_Service---C624F51F\blazorwasm\blazorwasm.csproj]
        C:\h\w\B0EC0997\t\dotnetSdkTests\zbey5ghz.0ec\.nuget\packages\microsoft.net.sdk.webassembly.pack\10.0.0-alpha.1.24509.15\build\Microsoft.NET.Sdk.WebAssembly.Browser.targets(366,5): error : WRN: Assembly binding logging is turned OFF. [C:\h\w\B0EC0997\t\dotnetSdkTests\zbey5ghz.0ec\Build_Service---C624F51F\blazorwasm\blazorwasm.csproj]
        C:\h\w\B0EC0997\t\dotnetSdkTests\zbey5ghz.0ec\.nuget\packages\microsoft.net.sdk.webassembly.pack\10.0.0-alpha.1.24509.15\build\Microsoft.NET.Sdk.WebAssembly.Browser.targets(366,5): error : To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1. [C:\h\w\B0EC0997\t\dotnetSdkTests\zbey5ghz.0ec\Build_Service---C624F51F\blazorwasm\blazorwasm.csproj]
        C:\h\w\B0EC0997\t\dotnetSdkTests\zbey5ghz.0ec\.nuget\packages\microsoft.net.sdk.webassembly.pack\10.0.0-alpha.1.24509.15\build\Microsoft.NET.Sdk.WebAssembly.Browser.targets(366,5): error : Note: There is some performance penalty associated with assembly bind failure logging. [C:\h\w\B0EC0997\t\dotnetSdkTests\zbey5ghz.0ec\Build_Service---C624F51F\blazorwasm\blazorwasm.csproj]
        C:\h\w\B0EC0997\t\dotnetSdkTests\zbey5ghz.0ec\.nuget\packages\microsoft.net.sdk.webassembly.pack\10.0.0-alpha.1.24509.15\build\Microsoft.NET.Sdk.WebAssembly.Browser.targets(366,5): error : To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog]. [C:\h\w\B0EC0997\t\dotnetSdkTests\zbey5ghz.0ec\Build_Service---C624F51F\blazorwasm\blazorwasm.csproj]
        C:\h\w\B0EC0997\t\dotnetSdkTests\zbey5ghz.0ec\.nuget\packages\microsoft.net.sdk.webassembly.pack\10.0.0-alpha.1.24509.15\build\Microsoft.NET.Sdk.WebAssembly.Browser.targets(366,5): error :  [C:\h\w\B0EC0997\t\dotnetSdkTests\zbey5ghz.0ec\Build_Service---C624F51F\blazorwasm\blazorwasm.csproj]

maraf avatar Oct 10 '24 19:10 maraf

@ericstj it looks like the task isn't finding the STJ it wants?

lewing avatar Oct 13 '24 11:10 lewing

@ericstj it looks like the task isn't finding the STJ it wants?

Tasks in the SDK need to keep S.T.J on either live (exact match, provided by SDK) or <= the one in VS / MSBuild (redirects will load). I previously tried to make more components in runtime use the live copy much of that failed because the test infrastructure for those components isn't set up correctly to test what is built. So long as we're referencing non-live bits we're going to be chasing CVE warnings / binding problems like this. It'd be much better to have them build against live bits.

ericstj avatar Oct 14 '24 14:10 ericstj

What version of System.Text.Json does the .NET framework MSBuild include? Are the tests using new enough VS?

maraf avatar Oct 15 '24 14:10 maraf

https://github.com/dotnet/sdk/pull/44011 is bringing this change https://github.com/dotnet/msbuild/commit/eacead39b9a7e0047c415db7318123c91af6f8e5#diff-2c2e83275077d3c65c1190f9aabc894271ab22132b4f5675f16fb1301c0639d8

kasperk81 avatar Oct 15 '24 16:10 kasperk81

/azp run dotnet-sdk-public-ci

dsplaisted avatar Oct 17 '24 18:10 dsplaisted

Azure Pipelines successfully started running 1 pipeline(s).

azure-pipelines[bot] avatar Oct 17 '24 18:10 azure-pipelines[bot]

Tasks in the SDK need to keep S.T.J on either live (exact match, provided by SDK) or <= the one in VS / MSBuild (redirects will load). I previously tried to make more components in runtime use the live copy much of that failed because the test infrastructure for those components isn't set up correctly to test what is built. So long as we're referencing non-live bits we're going to be chasing CVE warnings / binding problems like this. It'd be much better to have them build against live bits.

@ericstj If I'm understanding correctly, in the SDK build we have SystemTextJsonPackageVersion which is the live version, and SystemTextJsonToolsetPackageVersion which is the "VS or less" or "toolset" version, currently set to 8.0.4.

You're saying the only thing stopping us from using the live versions everywhere was some issues with the test infrastructure? Does perf in VS and the need for binding redirects if different modules build against different versions not also factor in to it?

/cc @rainersigwald

dsplaisted avatar Oct 17 '24 18:10 dsplaisted

/azp run sdk-source-build sdk-unified-build

dsplaisted avatar Oct 17 '24 18:10 dsplaisted

No pipelines are associated with this pull request.

azure-pipelines[bot] avatar Oct 17 '24 18:10 azure-pipelines[bot]

/azp run sdk-source-build

dsplaisted avatar Oct 17 '24 18:10 dsplaisted

Azure Pipelines successfully started running 1 pipeline(s).

azure-pipelines[bot] avatar Oct 17 '24 18:10 azure-pipelines[bot]

/azp run sdk-unified-build

dsplaisted avatar Oct 17 '24 18:10 dsplaisted

Azure Pipelines successfully started running 1 pipeline(s).

azure-pipelines[bot] avatar Oct 17 '24 18:10 azure-pipelines[bot]

You're saying the only thing stopping us from using the live versions everywhere was some issues with the test infrastructure?

This was specific to the use of Json in Microsoft.NET.HostModel. That component is built in a way that it can't easily take a dependency on the live version and test it, since its tests aren't running on the latest runtime. cc @agocke There are a couple other uses of Toolset versions of packages for things delivered to SDK from runtime.

Probably there are other blockers here on using live versions - like NuGet. Today we don't flow runtime through Nuget to get to the SDK, so it can't reference a live version. Roslyn and MSBuild are the same.

I think the solution in general is the plugin targeting pack solution - let these things target a baseline version that's guaranteed by the host (SDK or VS). The host will ensure it provides redirects for all the API exposed. The targeting pack will not carry with it any problematic dependencies / packages since it's only references.

ericstj avatar Oct 17 '24 19:10 ericstj

/vmr/artifacts/source-built-sdks/Microsoft.DotNet.Arcade.Sdk/tools/Publish.proj(228,5): error : Missing 'RelativeBlobPath' property on blob /vmr/src/runtime/artifacts/packages/Release/Shipping/dotnet-apphost-pack-10.0.0-alpha.1.24516.13-centos.9-x64.tar.gz

anyone looking into this?

kasperk81 avatar Oct 17 '24 19:10 kasperk81

Does perf in VS and the need for binding redirects if different modules build against different versions not also factor in to it?

Yes, you can get better perf in VS/MSBuild.exe scenarios by using the host-provided STJ, since we ngen it at VS install time and may have already loaded it.

rainersigwald avatar Oct 18 '24 17:10 rainersigwald

What version of System.Text.Json does the .NET framework MSBuild include? Are the tests using new enough VS?

VS 17.12 uses 8.0.5, and may be all we need to care about here in main/.NET 10, but the 17.12 Helix images haven't rolled out yet so the VS tests are still running against 17.11 AFAIK.

rainersigwald avatar Oct 18 '24 17:10 rainersigwald

/vmr/artifacts/source-built-sdks/Microsoft.DotNet.Arcade.Sdk/tools/Publish.proj(228,5): error : Missing 'RelativeBlobPath' property on blob /vmr/src/runtime/artifacts/packages/Release/Shipping/dotnet-apphost-pack-10.0.0-alpha.1.24516.13-centos.9-x64.tar.gz

anyone looking into this?

@dotnet/source-build to look into this, and @dotnet/product-construction to look at the unified build failures.

dsplaisted avatar Oct 18 '24 20:10 dsplaisted

@jkoritzinsky already has a pr up https://github.com/dotnet/runtime/pull/108990

kasperk81 avatar Oct 18 '24 20:10 kasperk81

What version of System.Text.Json does the .NET framework MSBuild include? Are the tests using new enough VS?

VS 17.12 uses 8.0.5, and may be all we need to care about here in main/.NET 10, but the 17.12 Helix images haven't rolled out yet so the VS tests are still running against 17.11 AFAIK.

@marcpopMSFT Do we know when we'll have VS 17.12 helix images available? Should we disable the failing tests (looks like they're all Blazor or Razor) on Full Framework for now?

dsplaisted avatar Oct 18 '24 20:10 dsplaisted

@marcpopMSFT Do we know when we'll have VS 17.12 helix images available? Should we disable the failing tests (looks like they're all Blazor or Razor) on Full Framework for now?

We don't have an ETA for that. It might be next week but I don't think we can count on that so it's potentially longer. Disabling in the full framework leg seems reasonable to me.

marcpopMSFT avatar Oct 18 '24 20:10 marcpopMSFT

I was wrong last week: 17.12 will have 8.0.5 but doesn't yet. It'll probably be in Preview 5.

rainersigwald avatar Oct 21 '24 14:10 rainersigwald

@dotnet/product-construction @dotnet/source-build This is now only failing with unified build and source-build errors. It looks like they are both failing due to a patch not applying:

fail: Failed to synchronize repo sdk
      Failed to apply the patch 0001-Rename-SourceBuildUseMonoRuntime-property-which-is-n.patch to src/runtime.
      
      Exit code: 1
      Std err:
      error: patch failed: src/runtime/eng/DotNetBuild.props:53
      error: src/runtime/eng/DotNetBuild.props: patch does not apply

dsplaisted avatar Oct 23 '24 14:10 dsplaisted

Done. I had to merge this branch with latest main.

ViktorHofer avatar Oct 23 '24 14:10 ViktorHofer

@ViktorHofer, it's currently blocked by https://github.com/dotnet/runtime/pull/108990. If it's ready, please go ahead and merge.

kasperk81 avatar Oct 23 '24 14:10 kasperk81

FYI, this is currently blocking CI builds which is why the installer table hasn't had an updated build in a while. That's becasue our CI pipeline is failing to package up the aspnet targeting pack

  dpkg: dependency problems prevent configuration of aspnetcore-targeting-pack-10.0:
   aspnetcore-targeting-pack-10.0 depends on dotnet-targeting-pack-10.0 (>= 10.0.0~alpha.1.24521.2); however:
    Version of dotnet-targeting-pack-10.0 on system is 10.0.0~alpha.1.24507.22.
  
  dpkg: error processing package aspnetcore-targeting-pack-10.0 (--install):

marcpopMSFT avatar Oct 23 '24 16:10 marcpopMSFT