[main] Update dotnet/runtime

[lewing]

Fix the 9.0.100 band in the emsdk transport package name

[lewing]

this may need additional tweaks to deal with the band versioning

[lewing]

Installer needs a bunch of updates as well once this lands

[jeffschwMSFT]

who is on point to either identifying the individual failures and farming out the work and/or handling them?

[mmitche]

@jeffschwMSFT There shouldn't be too much. This was the commit to switch to 8: 8119940

[lewing]

opened dotnet/arcade#14002 for future me

[lewing]

Looks like it is failing on rid resolution now @elinor-fung can you take a look?

[elinor-fung]

The built tests are configured to run on a runtime from before dotnet/docs#36466 for some reason.

If I build main, the runtimeconfig for the Microsoft.NET.Build.Tests has the runtime version corresponding to Version.props/Version.Details.xml:

 "runtimeOptions": {
"tfm": "net8.0",
"rollForward": "Major",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "8.0.0-rc.1.23421.3"
},

But from this branch, it has:

 "runtimeOptions": {
"tfm": "net8.0",
"rollForward": "Major",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "8.0.0-preview.7.23375.6"
},

I'm not sure why yet - cc @dsplaisted in case it is something obvious to you

[elinor-fung]

This is what does the updating to the runtime version that gets used by tests:

sdk/Directory.Build.targets

Lines 46 to 54 in aabbd97

	<!-- Update KnownFrameworkReferences to target the right version of the runtime -->
	<ItemGroupCondition="'$(TargetFrameworkIdentifier)' == '.NETCoreApp'
	and $(MicrosoftNETCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)'))
	and '$(MSBuildProjectName)' != 'toolset-tasks'">
	<FrameworkReference
	Update="Microsoft.NETCore.App"
	TargetingPackVersion="$(MicrosoftNETCoreAppRefPackageVersion)"
	RuntimeFrameworkVersion="$(MicrosoftNETCoreAppRuntimePackageVersion)" />
	</ItemGroup>

But with this PR, $(MicrosoftNETCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)')) is false:

• MicrosoftNETCoreAppRefPackageVersion is 9.0.0-alpha.1.23430.1
• _TargetFrameworkVersionWithoutV is 8.0

[elinor-fung]

@dsplaisted / @marcpopMSFT how does SDK usually handle updating major versions and targeting the consumed runtime version?

The retargeting for ASP.NET references has a similar condition:

sdk/Directory.Build.targets

Lines 56 to 63 in aabbd97

	<ItemGroupCondition="$(MicrosoftAspNetCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)'))">
	<KnownFrameworkReferenceUpdate="Microsoft.AspNetCore.App">
	<LatestRuntimeFrameworkVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</LatestRuntimeFrameworkVersion>
	<RuntimePackRuntimeIdentifiers>${SupportedRuntimeIdentifiers}</RuntimePackRuntimeIdentifiers>
	<TargetingPackVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</TargetingPackVersion>
	<DefaultRuntimeFrameworkVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</DefaultRuntimeFrameworkVersion>
	</KnownFrameworkReference>
	</ItemGroup>

[dsplaisted]

Now that the dependency flow is bringing in .NET 9 instead of .NET 8, the build doesn't have a version of .NET 8 to update the targeting to. I think the thing to do here is to update the stage 0 SDK to one that has a recent enough version of the runtime.

FYI for those not aware, here is where we are trying to keep track of the changes needed each time we update to a new TargetFramework: https://github.com/dotnet/sdk/blob/main/documentation/general/UpdateToNewTargetFramework.md Feel free to update it as appropriate.

[lewing]

@ViktorHofer @dotnet/domestic-cat please take a look

[baronfel]

@dsplaisted would you mind double-checking this and seeing if it matched what you were talking about?

[dsplaisted]

Yes, this matches what I expected. It might be better to use NuGetVersion instead of SemanticVersion. I'm not too sure of the differences between them, but the code I've seen has used NuGetVersion.

[marcpopMSFT]

latest change has us down to 34 test failures. @dotnet/source-build-internal @agocke@sbomer

1. Microsoft.NET.Sdk.BlazorWebAssembly.AoT.Tests.WasmAoTPublishIntegrationTest.AoT_Publish_WithExistingWebConfig_Works
   emcc : error : C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory ("C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a" was expected to be an input file, based on the commandline arguments provided) [C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\AoT_Publish_W---DA56BF44\blazorwasm\blazorwasm.csproj]
2. Microsoft.NET.Publish.Tests.GivenThatWeWantToPublishAnAotApp.NativeAotLib_errors_out_when_eventpipe_is_enabled
   Expected command to fail but it did not.
3. Source build is flagging the 8.0 downgrades I checked in to fix the System.Text.Json failure. Not sure what to do about this as it's meant to be temporary

Package IDs are:
Microsoft.Bcl.AsyncInterfaces.8.0.0-rc.1.23414.4
Microsoft.Extensions.DependencyModel.8.0.0-rc.1.23414.4
Microsoft.NET.HostModel.8.0.0-rc.1.23414.4```
There are a few other individual tests failures are unbuntu it looks like that also need to be looked into.

[elinor-fung]

Microsoft.NET.Publish.Tests.GivenThatWeWantToPublishAnAotApp.NativeAotLib_errors_out_when_eventpipe_is_enabled

Microsoft.DotNet.ILCompiler being used is now 8.0.0-rc.1.23414.4 - which is from before dotnet/runtime#90811 (main is using 8.0.0-rc.1.23421.3). Maybe related to the BundledVersions changes in this PR?

Side note: not the issue being hit in this PR, but that error is also being downgraded to a warning (dotnet/runtime#91715), so the test will also need to be updated when that change flows over.

[lewing]

I've updated the runtime flow to the most recent build. The wasm build is odd @maraf and @radical can you please take a look.

[elinor-fung]

C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory

Maybe the wasm error is the same as root cause as the native aot one - seems like the test environment gets constructed such that it is using older packages. As with Microsoft.DotNet.ILCompiler, the version of Microsoft.NETCore.App.Runtime.Mono.browser-wasm being used is an older version - 8.0.0-rc.1.23414.4 - which is before libmono-wasm-simd.a was added.

[radical]

C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory

This is because 9.0 targets are being used with a 8.0 runtime pack. I'm trying to reproduce this locally now.

[lewing]

Looks like we are down to NativeAOT publish failures now?

[marek-safar]

@sbomer@LakshanF could you help with resolving tests failures in AotStaticLibraryPublishWithEventPipe ?

[marek-safar]

@dotnet/source-build-internal could you please advise how to track where these prebuilts are coming from and how to version baseline-comparison.xml in 8.0 arcade for 9.0 main?

[MichaelSimons]

Is this intentionally incoherent with the other runtime dependencies? They are on version 9.0.0-alpha.1.23464.19 and sha a6c64c3c26417f579022e20cbcee992b4814ed2c. This is the source of the following source-build prebuilts that are being reported:

 <Usage Id="Microsoft.NETCore.DotNetAppHost" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json" />
<Usage Id="Microsoft.NETCore.DotNetAppHost" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json" />
<Usage Id="Microsoft.NETCore.DotNetHostResolver" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json" IsDirectDependency="true" />
<Usage Id="Microsoft.NETCore.DotNetHostResolver" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json" IsDirectDependency="true" />

[elinor-fung]

We actually removed Microsoft.NETCore.DotNetHostResolver in runtime. It looks like this repo is using it to grab hostfxr for Framework builds. I think it can use Microsoft.NETCore.App.Runtime.* packages - I'll take a look.

[MichaelSimons]

@dotnet/source-build-internal could you please advise how to track where these prebuilts are coming from and how to version baseline-comparison.xml in 8.0 arcade for 9.0 main?

I took a quick look. Here is what I did:

1. Reviewed the prebuilt baseline-comparison.xml.
2. Noted two classes of prebuilts as they come from two different project groupings.
3. First grouping is from src/artifacts/obj/Release/Sdks/Microsoft.NET.Sdk/tools/project.assets.json which when looking at the changes led me to this conclusion.
4. Second grouping is from src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json and src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json which led me to review the version of the referenced prebuilts in the versions.props and version.details.xml and noticed this incoherency.

[elinor-fung]

Second grouping from Microsoft.DotNet.MSBuildSdkResolver / Microsoft.DotNet.SdkResolver is resolved.

#35048 (comment) is all that is left.

[lewing]

@marcpopMSFT ping

[lewing]

Fix the 9.0.100 band in the emsdk transport package name

[lewing]

this may need additional tweaks to deal with the band versioning

[lewing]

Installer needs a bunch of updates as well once this lands

[jeffschwMSFT]

who is on point to either identifying the individual failures and farming out the work and/or handling them?

[mmitche]

@jeffschwMSFT There shouldn't be too much. This was the commit to switch to 8: 8119940

[lewing]

opened dotnet/arcade#14002 for future me

[lewing]

Looks like it is failing on rid resolution now @elinor-fung can you take a look?

[elinor-fung]

The built tests are configured to run on a runtime from before dotnet/docs#36466 for some reason.

If I build main, the runtimeconfig for the Microsoft.NET.Build.Tests has the runtime version corresponding to Version.props/Version.Details.xml:

 "runtimeOptions": {
"tfm": "net8.0",
"rollForward": "Major",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "8.0.0-rc.1.23421.3"
},

But from this branch, it has:

 "runtimeOptions": {
"tfm": "net8.0",
"rollForward": "Major",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "8.0.0-preview.7.23375.6"
},

I'm not sure why yet - cc @dsplaisted in case it is something obvious to you

[elinor-fung]

This is what does the updating to the runtime version that gets used by tests:

sdk/Directory.Build.targets

Lines 46 to 54 in aabbd97

	<!-- Update KnownFrameworkReferences to target the right version of the runtime -->
	<ItemGroupCondition="'$(TargetFrameworkIdentifier)' == '.NETCoreApp'
	and $(MicrosoftNETCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)'))
	and '$(MSBuildProjectName)' != 'toolset-tasks'">
	<FrameworkReference
	Update="Microsoft.NETCore.App"
	TargetingPackVersion="$(MicrosoftNETCoreAppRefPackageVersion)"
	RuntimeFrameworkVersion="$(MicrosoftNETCoreAppRuntimePackageVersion)" />
	</ItemGroup>

But with this PR, $(MicrosoftNETCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)')) is false:

• MicrosoftNETCoreAppRefPackageVersion is 9.0.0-alpha.1.23430.1
• _TargetFrameworkVersionWithoutV is 8.0

[elinor-fung]

@dsplaisted / @marcpopMSFT how does SDK usually handle updating major versions and targeting the consumed runtime version?

The retargeting for ASP.NET references has a similar condition:

sdk/Directory.Build.targets

Lines 56 to 63 in aabbd97

	<ItemGroupCondition="$(MicrosoftAspNetCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)'))">
	<KnownFrameworkReferenceUpdate="Microsoft.AspNetCore.App">
	<LatestRuntimeFrameworkVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</LatestRuntimeFrameworkVersion>
	<RuntimePackRuntimeIdentifiers>${SupportedRuntimeIdentifiers}</RuntimePackRuntimeIdentifiers>
	<TargetingPackVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</TargetingPackVersion>
	<DefaultRuntimeFrameworkVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</DefaultRuntimeFrameworkVersion>
	</KnownFrameworkReference>
	</ItemGroup>

[dsplaisted]

Now that the dependency flow is bringing in .NET 9 instead of .NET 8, the build doesn't have a version of .NET 8 to update the targeting to. I think the thing to do here is to update the stage 0 SDK to one that has a recent enough version of the runtime.

FYI for those not aware, here is where we are trying to keep track of the changes needed each time we update to a new TargetFramework: https://github.com/dotnet/sdk/blob/main/documentation/general/UpdateToNewTargetFramework.md Feel free to update it as appropriate.

[lewing]

@ViktorHofer @dotnet/domestic-cat please take a look

[baronfel]

@dsplaisted would you mind double-checking this and seeing if it matched what you were talking about?

[dsplaisted]

Yes, this matches what I expected. It might be better to use NuGetVersion instead of SemanticVersion. I'm not too sure of the differences between them, but the code I've seen has used NuGetVersion.

[marcpopMSFT]

latest change has us down to 34 test failures. @dotnet/source-build-internal @agocke@sbomer

1. Microsoft.NET.Sdk.BlazorWebAssembly.AoT.Tests.WasmAoTPublishIntegrationTest.AoT_Publish_WithExistingWebConfig_Works
   emcc : error : C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory ("C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a" was expected to be an input file, based on the commandline arguments provided) [C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\AoT_Publish_W---DA56BF44\blazorwasm\blazorwasm.csproj]
2. Microsoft.NET.Publish.Tests.GivenThatWeWantToPublishAnAotApp.NativeAotLib_errors_out_when_eventpipe_is_enabled
   Expected command to fail but it did not.
3. Source build is flagging the 8.0 downgrades I checked in to fix the System.Text.Json failure. Not sure what to do about this as it's meant to be temporary

Package IDs are:
Microsoft.Bcl.AsyncInterfaces.8.0.0-rc.1.23414.4
Microsoft.Extensions.DependencyModel.8.0.0-rc.1.23414.4
Microsoft.NET.HostModel.8.0.0-rc.1.23414.4```
There are a few other individual tests failures are unbuntu it looks like that also need to be looked into.

[elinor-fung]

Microsoft.NET.Publish.Tests.GivenThatWeWantToPublishAnAotApp.NativeAotLib_errors_out_when_eventpipe_is_enabled

Microsoft.DotNet.ILCompiler being used is now 8.0.0-rc.1.23414.4 - which is from before dotnet/runtime#90811 (main is using 8.0.0-rc.1.23421.3). Maybe related to the BundledVersions changes in this PR?

Side note: not the issue being hit in this PR, but that error is also being downgraded to a warning (dotnet/runtime#91715), so the test will also need to be updated when that change flows over.

[lewing]

I've updated the runtime flow to the most recent build. The wasm build is odd @maraf and @radical can you please take a look.

[elinor-fung]

C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory

Maybe the wasm error is the same as root cause as the native aot one - seems like the test environment gets constructed such that it is using older packages. As with Microsoft.DotNet.ILCompiler, the version of Microsoft.NETCore.App.Runtime.Mono.browser-wasm being used is an older version - 8.0.0-rc.1.23414.4 - which is before libmono-wasm-simd.a was added.

[radical]

C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory

This is because 9.0 targets are being used with a 8.0 runtime pack. I'm trying to reproduce this locally now.

[lewing]

Looks like we are down to NativeAOT publish failures now?

[marek-safar]

@sbomer@LakshanF could you help with resolving tests failures in AotStaticLibraryPublishWithEventPipe ?

[marek-safar]

@dotnet/source-build-internal could you please advise how to track where these prebuilts are coming from and how to version baseline-comparison.xml in 8.0 arcade for 9.0 main?

[MichaelSimons]

Is this intentionally incoherent with the other runtime dependencies? They are on version 9.0.0-alpha.1.23464.19 and sha a6c64c3c26417f579022e20cbcee992b4814ed2c. This is the source of the following source-build prebuilts that are being reported:

 <Usage Id="Microsoft.NETCore.DotNetAppHost" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json" />
<Usage Id="Microsoft.NETCore.DotNetAppHost" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json" />
<Usage Id="Microsoft.NETCore.DotNetHostResolver" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json" IsDirectDependency="true" />
<Usage Id="Microsoft.NETCore.DotNetHostResolver" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json" IsDirectDependency="true" />

[elinor-fung]

We actually removed Microsoft.NETCore.DotNetHostResolver in runtime. It looks like this repo is using it to grab hostfxr for Framework builds. I think it can use Microsoft.NETCore.App.Runtime.* packages - I'll take a look.

[MichaelSimons]

@dotnet/source-build-internal could you please advise how to track where these prebuilts are coming from and how to version baseline-comparison.xml in 8.0 arcade for 9.0 main?

I took a quick look. Here is what I did:

1. Reviewed the prebuilt baseline-comparison.xml.
2. Noted two classes of prebuilts as they come from two different project groupings.
3. First grouping is from src/artifacts/obj/Release/Sdks/Microsoft.NET.Sdk/tools/project.assets.json which when looking at the changes led me to this conclusion.
4. Second grouping is from src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json and src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json which led me to review the version of the referenced prebuilts in the versions.props and version.details.xml and noticed this incoherency.

[elinor-fung]

Second grouping from Microsoft.DotNet.MSBuildSdkResolver / Microsoft.DotNet.SdkResolver is resolved.

#35048 (comment) is all that is left.

[lewing]

@marcpopMSFT ping

[lewing]

Fix the 9.0.100 band in the emsdk transport package name

[lewing]

this may need additional tweaks to deal with the band versioning

[lewing]

Installer needs a bunch of updates as well once this lands

[jeffschwMSFT]

who is on point to either identifying the individual failures and farming out the work and/or handling them?

[mmitche]

@jeffschwMSFT There shouldn't be too much. This was the commit to switch to 8: 8119940

[lewing]

opened dotnet/arcade#14002 for future me

[lewing]

Looks like it is failing on rid resolution now @elinor-fung can you take a look?

[elinor-fung]

The built tests are configured to run on a runtime from before dotnet/docs#36466 for some reason.

If I build main, the runtimeconfig for the Microsoft.NET.Build.Tests has the runtime version corresponding to Version.props/Version.Details.xml:

 "runtimeOptions": {
"tfm": "net8.0",
"rollForward": "Major",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "8.0.0-rc.1.23421.3"
},

But from this branch, it has:

 "runtimeOptions": {
"tfm": "net8.0",
"rollForward": "Major",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "8.0.0-preview.7.23375.6"
},

I'm not sure why yet - cc @dsplaisted in case it is something obvious to you

[elinor-fung]

This is what does the updating to the runtime version that gets used by tests:

sdk/Directory.Build.targets

Lines 46 to 54 in aabbd97

	<!-- Update KnownFrameworkReferences to target the right version of the runtime -->
	<ItemGroupCondition="'$(TargetFrameworkIdentifier)' == '.NETCoreApp'
	and $(MicrosoftNETCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)'))
	and '$(MSBuildProjectName)' != 'toolset-tasks'">
	<FrameworkReference
	Update="Microsoft.NETCore.App"
	TargetingPackVersion="$(MicrosoftNETCoreAppRefPackageVersion)"
	RuntimeFrameworkVersion="$(MicrosoftNETCoreAppRuntimePackageVersion)" />
	</ItemGroup>

But with this PR, $(MicrosoftNETCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)')) is false:

• MicrosoftNETCoreAppRefPackageVersion is 9.0.0-alpha.1.23430.1
• _TargetFrameworkVersionWithoutV is 8.0

[elinor-fung]

@dsplaisted / @marcpopMSFT how does SDK usually handle updating major versions and targeting the consumed runtime version?

The retargeting for ASP.NET references has a similar condition:

sdk/Directory.Build.targets

Lines 56 to 63 in aabbd97

	<ItemGroupCondition="$(MicrosoftAspNetCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)'))">
	<KnownFrameworkReferenceUpdate="Microsoft.AspNetCore.App">
	<LatestRuntimeFrameworkVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</LatestRuntimeFrameworkVersion>
	<RuntimePackRuntimeIdentifiers>${SupportedRuntimeIdentifiers}</RuntimePackRuntimeIdentifiers>
	<TargetingPackVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</TargetingPackVersion>
	<DefaultRuntimeFrameworkVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</DefaultRuntimeFrameworkVersion>
	</KnownFrameworkReference>
	</ItemGroup>

[dsplaisted]

Now that the dependency flow is bringing in .NET 9 instead of .NET 8, the build doesn't have a version of .NET 8 to update the targeting to. I think the thing to do here is to update the stage 0 SDK to one that has a recent enough version of the runtime.

FYI for those not aware, here is where we are trying to keep track of the changes needed each time we update to a new TargetFramework: https://github.com/dotnet/sdk/blob/main/documentation/general/UpdateToNewTargetFramework.md Feel free to update it as appropriate.

[lewing]

@ViktorHofer @dotnet/domestic-cat please take a look

[baronfel]

@dsplaisted would you mind double-checking this and seeing if it matched what you were talking about?

[dsplaisted]

Yes, this matches what I expected. It might be better to use NuGetVersion instead of SemanticVersion. I'm not too sure of the differences between them, but the code I've seen has used NuGetVersion.

[marcpopMSFT]

latest change has us down to 34 test failures. @dotnet/source-build-internal @agocke@sbomer

1. Microsoft.NET.Sdk.BlazorWebAssembly.AoT.Tests.WasmAoTPublishIntegrationTest.AoT_Publish_WithExistingWebConfig_Works
   emcc : error : C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory ("C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a" was expected to be an input file, based on the commandline arguments provided) [C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\AoT_Publish_W---DA56BF44\blazorwasm\blazorwasm.csproj]
2. Microsoft.NET.Publish.Tests.GivenThatWeWantToPublishAnAotApp.NativeAotLib_errors_out_when_eventpipe_is_enabled
   Expected command to fail but it did not.
3. Source build is flagging the 8.0 downgrades I checked in to fix the System.Text.Json failure. Not sure what to do about this as it's meant to be temporary

Package IDs are:
Microsoft.Bcl.AsyncInterfaces.8.0.0-rc.1.23414.4
Microsoft.Extensions.DependencyModel.8.0.0-rc.1.23414.4
Microsoft.NET.HostModel.8.0.0-rc.1.23414.4```
There are a few other individual tests failures are unbuntu it looks like that also need to be looked into.

[elinor-fung]

Microsoft.NET.Publish.Tests.GivenThatWeWantToPublishAnAotApp.NativeAotLib_errors_out_when_eventpipe_is_enabled

Microsoft.DotNet.ILCompiler being used is now 8.0.0-rc.1.23414.4 - which is from before dotnet/runtime#90811 (main is using 8.0.0-rc.1.23421.3). Maybe related to the BundledVersions changes in this PR?

Side note: not the issue being hit in this PR, but that error is also being downgraded to a warning (dotnet/runtime#91715), so the test will also need to be updated when that change flows over.

[lewing]

I've updated the runtime flow to the most recent build. The wasm build is odd @maraf and @radical can you please take a look.

[elinor-fung]

C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory

Maybe the wasm error is the same as root cause as the native aot one - seems like the test environment gets constructed such that it is using older packages. As with Microsoft.DotNet.ILCompiler, the version of Microsoft.NETCore.App.Runtime.Mono.browser-wasm being used is an older version - 8.0.0-rc.1.23414.4 - which is before libmono-wasm-simd.a was added.

[radical]

C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory

This is because 9.0 targets are being used with a 8.0 runtime pack. I'm trying to reproduce this locally now.

[lewing]

Looks like we are down to NativeAOT publish failures now?

[marek-safar]

@sbomer@LakshanF could you help with resolving tests failures in AotStaticLibraryPublishWithEventPipe ?

[marek-safar]

@dotnet/source-build-internal could you please advise how to track where these prebuilts are coming from and how to version baseline-comparison.xml in 8.0 arcade for 9.0 main?

[MichaelSimons]

Is this intentionally incoherent with the other runtime dependencies? They are on version 9.0.0-alpha.1.23464.19 and sha a6c64c3c26417f579022e20cbcee992b4814ed2c. This is the source of the following source-build prebuilts that are being reported:

 <Usage Id="Microsoft.NETCore.DotNetAppHost" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json" />
<Usage Id="Microsoft.NETCore.DotNetAppHost" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json" />
<Usage Id="Microsoft.NETCore.DotNetHostResolver" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json" IsDirectDependency="true" />
<Usage Id="Microsoft.NETCore.DotNetHostResolver" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json" IsDirectDependency="true" />

[elinor-fung]

We actually removed Microsoft.NETCore.DotNetHostResolver in runtime. It looks like this repo is using it to grab hostfxr for Framework builds. I think it can use Microsoft.NETCore.App.Runtime.* packages - I'll take a look.

[MichaelSimons]

@dotnet/source-build-internal could you please advise how to track where these prebuilts are coming from and how to version baseline-comparison.xml in 8.0 arcade for 9.0 main?

I took a quick look. Here is what I did:

1. Reviewed the prebuilt baseline-comparison.xml.
2. Noted two classes of prebuilts as they come from two different project groupings.
3. First grouping is from src/artifacts/obj/Release/Sdks/Microsoft.NET.Sdk/tools/project.assets.json which when looking at the changes led me to this conclusion.
4. Second grouping is from src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json and src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json which led me to review the version of the referenced prebuilts in the versions.props and version.details.xml and noticed this incoherency.

[elinor-fung]

Second grouping from Microsoft.DotNet.MSBuildSdkResolver / Microsoft.DotNet.SdkResolver is resolved.

#35048 (comment) is all that is left.

[lewing]

@marcpopMSFT ping

[lewing]

Fix the 9.0.100 band in the emsdk transport package name

[lewing]

this may need additional tweaks to deal with the band versioning

[lewing]

Installer needs a bunch of updates as well once this lands

[jeffschwMSFT]

who is on point to either identifying the individual failures and farming out the work and/or handling them?

[mmitche]

@jeffschwMSFT There shouldn't be too much. This was the commit to switch to 8: 8119940

[lewing]

opened dotnet/arcade#14002 for future me

[lewing]

Looks like it is failing on rid resolution now @elinor-fung can you take a look?

[elinor-fung]

The built tests are configured to run on a runtime from before dotnet/docs#36466 for some reason.

If I build main, the runtimeconfig for the Microsoft.NET.Build.Tests has the runtime version corresponding to Version.props/Version.Details.xml:

 "runtimeOptions": {
"tfm": "net8.0",
"rollForward": "Major",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "8.0.0-rc.1.23421.3"
},

But from this branch, it has:

 "runtimeOptions": {
"tfm": "net8.0",
"rollForward": "Major",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "8.0.0-preview.7.23375.6"
},

I'm not sure why yet - cc @dsplaisted in case it is something obvious to you

[elinor-fung]

This is what does the updating to the runtime version that gets used by tests:

sdk/Directory.Build.targets

Lines 46 to 54 in aabbd97

	<!-- Update KnownFrameworkReferences to target the right version of the runtime -->
	<ItemGroupCondition="'$(TargetFrameworkIdentifier)' == '.NETCoreApp'
	and $(MicrosoftNETCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)'))
	and '$(MSBuildProjectName)' != 'toolset-tasks'">
	<FrameworkReference
	Update="Microsoft.NETCore.App"
	TargetingPackVersion="$(MicrosoftNETCoreAppRefPackageVersion)"
	RuntimeFrameworkVersion="$(MicrosoftNETCoreAppRuntimePackageVersion)" />
	</ItemGroup>

But with this PR, $(MicrosoftNETCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)')) is false:

• MicrosoftNETCoreAppRefPackageVersion is 9.0.0-alpha.1.23430.1
• _TargetFrameworkVersionWithoutV is 8.0

[elinor-fung]

@dsplaisted / @marcpopMSFT how does SDK usually handle updating major versions and targeting the consumed runtime version?

The retargeting for ASP.NET references has a similar condition:

sdk/Directory.Build.targets

Lines 56 to 63 in aabbd97

	<ItemGroupCondition="$(MicrosoftAspNetCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)'))">
	<KnownFrameworkReferenceUpdate="Microsoft.AspNetCore.App">
	<LatestRuntimeFrameworkVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</LatestRuntimeFrameworkVersion>
	<RuntimePackRuntimeIdentifiers>${SupportedRuntimeIdentifiers}</RuntimePackRuntimeIdentifiers>
	<TargetingPackVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</TargetingPackVersion>
	<DefaultRuntimeFrameworkVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</DefaultRuntimeFrameworkVersion>
	</KnownFrameworkReference>
	</ItemGroup>

[dsplaisted]

Now that the dependency flow is bringing in .NET 9 instead of .NET 8, the build doesn't have a version of .NET 8 to update the targeting to. I think the thing to do here is to update the stage 0 SDK to one that has a recent enough version of the runtime.

FYI for those not aware, here is where we are trying to keep track of the changes needed each time we update to a new TargetFramework: https://github.com/dotnet/sdk/blob/main/documentation/general/UpdateToNewTargetFramework.md Feel free to update it as appropriate.

[lewing]

@ViktorHofer @dotnet/domestic-cat please take a look

[baronfel]

@dsplaisted would you mind double-checking this and seeing if it matched what you were talking about?

[dsplaisted]

Yes, this matches what I expected. It might be better to use NuGetVersion instead of SemanticVersion. I'm not too sure of the differences between them, but the code I've seen has used NuGetVersion.

[marcpopMSFT]

latest change has us down to 34 test failures. @dotnet/source-build-internal @agocke@sbomer

1. Microsoft.NET.Sdk.BlazorWebAssembly.AoT.Tests.WasmAoTPublishIntegrationTest.AoT_Publish_WithExistingWebConfig_Works
   emcc : error : C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory ("C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a" was expected to be an input file, based on the commandline arguments provided) [C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\AoT_Publish_W---DA56BF44\blazorwasm\blazorwasm.csproj]
2. Microsoft.NET.Publish.Tests.GivenThatWeWantToPublishAnAotApp.NativeAotLib_errors_out_when_eventpipe_is_enabled
   Expected command to fail but it did not.
3. Source build is flagging the 8.0 downgrades I checked in to fix the System.Text.Json failure. Not sure what to do about this as it's meant to be temporary

Package IDs are:
Microsoft.Bcl.AsyncInterfaces.8.0.0-rc.1.23414.4
Microsoft.Extensions.DependencyModel.8.0.0-rc.1.23414.4
Microsoft.NET.HostModel.8.0.0-rc.1.23414.4```
There are a few other individual tests failures are unbuntu it looks like that also need to be looked into.

[elinor-fung]

Microsoft.NET.Publish.Tests.GivenThatWeWantToPublishAnAotApp.NativeAotLib_errors_out_when_eventpipe_is_enabled

Microsoft.DotNet.ILCompiler being used is now 8.0.0-rc.1.23414.4 - which is from before dotnet/runtime#90811 (main is using 8.0.0-rc.1.23421.3). Maybe related to the BundledVersions changes in this PR?

Side note: not the issue being hit in this PR, but that error is also being downgraded to a warning (dotnet/runtime#91715), so the test will also need to be updated when that change flows over.

[lewing]

I've updated the runtime flow to the most recent build. The wasm build is odd @maraf and @radical can you please take a look.

[elinor-fung]

C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory

Maybe the wasm error is the same as root cause as the native aot one - seems like the test environment gets constructed such that it is using older packages. As with Microsoft.DotNet.ILCompiler, the version of Microsoft.NETCore.App.Runtime.Mono.browser-wasm being used is an older version - 8.0.0-rc.1.23414.4 - which is before libmono-wasm-simd.a was added.

[radical]

C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory

This is because 9.0 targets are being used with a 8.0 runtime pack. I'm trying to reproduce this locally now.

[lewing]

Looks like we are down to NativeAOT publish failures now?

[marek-safar]

@sbomer@LakshanF could you help with resolving tests failures in AotStaticLibraryPublishWithEventPipe ?

[marek-safar]

@dotnet/source-build-internal could you please advise how to track where these prebuilts are coming from and how to version baseline-comparison.xml in 8.0 arcade for 9.0 main?

[MichaelSimons]

Is this intentionally incoherent with the other runtime dependencies? They are on version 9.0.0-alpha.1.23464.19 and sha a6c64c3c26417f579022e20cbcee992b4814ed2c. This is the source of the following source-build prebuilts that are being reported:

 <Usage Id="Microsoft.NETCore.DotNetAppHost" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json" />
<Usage Id="Microsoft.NETCore.DotNetAppHost" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json" />
<Usage Id="Microsoft.NETCore.DotNetHostResolver" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json" IsDirectDependency="true" />
<Usage Id="Microsoft.NETCore.DotNetHostResolver" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json" IsDirectDependency="true" />

[elinor-fung]

We actually removed Microsoft.NETCore.DotNetHostResolver in runtime. It looks like this repo is using it to grab hostfxr for Framework builds. I think it can use Microsoft.NETCore.App.Runtime.* packages - I'll take a look.

[MichaelSimons]

@dotnet/source-build-internal could you please advise how to track where these prebuilts are coming from and how to version baseline-comparison.xml in 8.0 arcade for 9.0 main?

I took a quick look. Here is what I did:

1. Reviewed the prebuilt baseline-comparison.xml.
2. Noted two classes of prebuilts as they come from two different project groupings.
3. First grouping is from src/artifacts/obj/Release/Sdks/Microsoft.NET.Sdk/tools/project.assets.json which when looking at the changes led me to this conclusion.
4. Second grouping is from src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json and src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json which led me to review the version of the referenced prebuilts in the versions.props and version.details.xml and noticed this incoherency.

[elinor-fung]

Second grouping from Microsoft.DotNet.MSBuildSdkResolver / Microsoft.DotNet.SdkResolver is resolved.

#35048 (comment) is all that is left.

[lewing]

@marcpopMSFT ping

[lewing]

Fix the 9.0.100 band in the emsdk transport package name

[lewing]

this may need additional tweaks to deal with the band versioning

[lewing]

Installer needs a bunch of updates as well once this lands

[jeffschwMSFT]

who is on point to either identifying the individual failures and farming out the work and/or handling them?

[mmitche]

@jeffschwMSFT There shouldn't be too much. This was the commit to switch to 8: 8119940

[lewing]

opened dotnet/arcade#14002 for future me

[lewing]

Looks like it is failing on rid resolution now @elinor-fung can you take a look?

[elinor-fung]

The built tests are configured to run on a runtime from before dotnet/docs#36466 for some reason.

If I build main, the runtimeconfig for the Microsoft.NET.Build.Tests has the runtime version corresponding to Version.props/Version.Details.xml:

 "runtimeOptions": {
"tfm": "net8.0",
"rollForward": "Major",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "8.0.0-rc.1.23421.3"
},

But from this branch, it has:

 "runtimeOptions": {
"tfm": "net8.0",
"rollForward": "Major",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "8.0.0-preview.7.23375.6"
},

I'm not sure why yet - cc @dsplaisted in case it is something obvious to you

[elinor-fung]

This is what does the updating to the runtime version that gets used by tests:

sdk/Directory.Build.targets

Lines 46 to 54 in aabbd97

	<!-- Update KnownFrameworkReferences to target the right version of the runtime -->
	<ItemGroupCondition="'$(TargetFrameworkIdentifier)' == '.NETCoreApp'
	and $(MicrosoftNETCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)'))
	and '$(MSBuildProjectName)' != 'toolset-tasks'">
	<FrameworkReference
	Update="Microsoft.NETCore.App"
	TargetingPackVersion="$(MicrosoftNETCoreAppRefPackageVersion)"
	RuntimeFrameworkVersion="$(MicrosoftNETCoreAppRuntimePackageVersion)" />
	</ItemGroup>

But with this PR, $(MicrosoftNETCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)')) is false:

• MicrosoftNETCoreAppRefPackageVersion is 9.0.0-alpha.1.23430.1
• _TargetFrameworkVersionWithoutV is 8.0

[elinor-fung]

@dsplaisted / @marcpopMSFT how does SDK usually handle updating major versions and targeting the consumed runtime version?

The retargeting for ASP.NET references has a similar condition:

sdk/Directory.Build.targets

Lines 56 to 63 in aabbd97

	<ItemGroupCondition="$(MicrosoftAspNetCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)'))">
	<KnownFrameworkReferenceUpdate="Microsoft.AspNetCore.App">
	<LatestRuntimeFrameworkVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</LatestRuntimeFrameworkVersion>
	<RuntimePackRuntimeIdentifiers>${SupportedRuntimeIdentifiers}</RuntimePackRuntimeIdentifiers>
	<TargetingPackVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</TargetingPackVersion>
	<DefaultRuntimeFrameworkVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</DefaultRuntimeFrameworkVersion>
	</KnownFrameworkReference>
	</ItemGroup>

[dsplaisted]

Now that the dependency flow is bringing in .NET 9 instead of .NET 8, the build doesn't have a version of .NET 8 to update the targeting to. I think the thing to do here is to update the stage 0 SDK to one that has a recent enough version of the runtime.

FYI for those not aware, here is where we are trying to keep track of the changes needed each time we update to a new TargetFramework: https://github.com/dotnet/sdk/blob/main/documentation/general/UpdateToNewTargetFramework.md Feel free to update it as appropriate.

[lewing]

@ViktorHofer @dotnet/domestic-cat please take a look

[baronfel]

@dsplaisted would you mind double-checking this and seeing if it matched what you were talking about?

[dsplaisted]

Yes, this matches what I expected. It might be better to use NuGetVersion instead of SemanticVersion. I'm not too sure of the differences between them, but the code I've seen has used NuGetVersion.

[marcpopMSFT]

latest change has us down to 34 test failures. @dotnet/source-build-internal @agocke@sbomer

1. Microsoft.NET.Sdk.BlazorWebAssembly.AoT.Tests.WasmAoTPublishIntegrationTest.AoT_Publish_WithExistingWebConfig_Works
   emcc : error : C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory ("C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a" was expected to be an input file, based on the commandline arguments provided) [C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\AoT_Publish_W---DA56BF44\blazorwasm\blazorwasm.csproj]
2. Microsoft.NET.Publish.Tests.GivenThatWeWantToPublishAnAotApp.NativeAotLib_errors_out_when_eventpipe_is_enabled
   Expected command to fail but it did not.
3. Source build is flagging the 8.0 downgrades I checked in to fix the System.Text.Json failure. Not sure what to do about this as it's meant to be temporary

Package IDs are:
Microsoft.Bcl.AsyncInterfaces.8.0.0-rc.1.23414.4
Microsoft.Extensions.DependencyModel.8.0.0-rc.1.23414.4
Microsoft.NET.HostModel.8.0.0-rc.1.23414.4```
There are a few other individual tests failures are unbuntu it looks like that also need to be looked into.

[elinor-fung]

Microsoft.NET.Publish.Tests.GivenThatWeWantToPublishAnAotApp.NativeAotLib_errors_out_when_eventpipe_is_enabled

Microsoft.DotNet.ILCompiler being used is now 8.0.0-rc.1.23414.4 - which is from before dotnet/runtime#90811 (main is using 8.0.0-rc.1.23421.3). Maybe related to the BundledVersions changes in this PR?

Side note: not the issue being hit in this PR, but that error is also being downgraded to a warning (dotnet/runtime#91715), so the test will also need to be updated when that change flows over.

[lewing]

I've updated the runtime flow to the most recent build. The wasm build is odd @maraf and @radical can you please take a look.

[elinor-fung]

C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory

Maybe the wasm error is the same as root cause as the native aot one - seems like the test environment gets constructed such that it is using older packages. As with Microsoft.DotNet.ILCompiler, the version of Microsoft.NETCore.App.Runtime.Mono.browser-wasm being used is an older version - 8.0.0-rc.1.23414.4 - which is before libmono-wasm-simd.a was added.

[radical]

C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory

This is because 9.0 targets are being used with a 8.0 runtime pack. I'm trying to reproduce this locally now.

[lewing]

Looks like we are down to NativeAOT publish failures now?

[marek-safar]

@sbomer@LakshanF could you help with resolving tests failures in AotStaticLibraryPublishWithEventPipe ?

[marek-safar]

@dotnet/source-build-internal could you please advise how to track where these prebuilts are coming from and how to version baseline-comparison.xml in 8.0 arcade for 9.0 main?

[MichaelSimons]

Is this intentionally incoherent with the other runtime dependencies? They are on version 9.0.0-alpha.1.23464.19 and sha a6c64c3c26417f579022e20cbcee992b4814ed2c. This is the source of the following source-build prebuilts that are being reported:

 <Usage Id="Microsoft.NETCore.DotNetAppHost" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json" />
<Usage Id="Microsoft.NETCore.DotNetAppHost" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json" />
<Usage Id="Microsoft.NETCore.DotNetHostResolver" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json" IsDirectDependency="true" />
<Usage Id="Microsoft.NETCore.DotNetHostResolver" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json" IsDirectDependency="true" />

[elinor-fung]

We actually removed Microsoft.NETCore.DotNetHostResolver in runtime. It looks like this repo is using it to grab hostfxr for Framework builds. I think it can use Microsoft.NETCore.App.Runtime.* packages - I'll take a look.

[MichaelSimons]

@dotnet/source-build-internal could you please advise how to track where these prebuilts are coming from and how to version baseline-comparison.xml in 8.0 arcade for 9.0 main?

I took a quick look. Here is what I did:

1. Reviewed the prebuilt baseline-comparison.xml.
2. Noted two classes of prebuilts as they come from two different project groupings.
3. First grouping is from src/artifacts/obj/Release/Sdks/Microsoft.NET.Sdk/tools/project.assets.json which when looking at the changes led me to this conclusion.
4. Second grouping is from src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json and src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json which led me to review the version of the referenced prebuilts in the versions.props and version.details.xml and noticed this incoherency.

[elinor-fung]

Second grouping from Microsoft.DotNet.MSBuildSdkResolver / Microsoft.DotNet.SdkResolver is resolved.

#35048 (comment) is all that is left.

[lewing]

@marcpopMSFT ping

[lewing]

Fix the 9.0.100 band in the emsdk transport package name

[lewing]

this may need additional tweaks to deal with the band versioning

[lewing]

Installer needs a bunch of updates as well once this lands

[jeffschwMSFT]

who is on point to either identifying the individual failures and farming out the work and/or handling them?

[mmitche]

@jeffschwMSFT There shouldn't be too much. This was the commit to switch to 8: 8119940

[lewing]

opened dotnet/arcade#14002 for future me

[lewing]

Looks like it is failing on rid resolution now @elinor-fung can you take a look?

[elinor-fung]

The built tests are configured to run on a runtime from before dotnet/docs#36466 for some reason.

If I build main, the runtimeconfig for the Microsoft.NET.Build.Tests has the runtime version corresponding to Version.props/Version.Details.xml:

 "runtimeOptions": {
"tfm": "net8.0",
"rollForward": "Major",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "8.0.0-rc.1.23421.3"
},

But from this branch, it has:

 "runtimeOptions": {
"tfm": "net8.0",
"rollForward": "Major",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "8.0.0-preview.7.23375.6"
},

I'm not sure why yet - cc @dsplaisted in case it is something obvious to you

[elinor-fung]

This is what does the updating to the runtime version that gets used by tests:

sdk/Directory.Build.targets

Lines 46 to 54 in aabbd97

	<!-- Update KnownFrameworkReferences to target the right version of the runtime -->
	<ItemGroupCondition="'$(TargetFrameworkIdentifier)' == '.NETCoreApp'
	and $(MicrosoftNETCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)'))
	and '$(MSBuildProjectName)' != 'toolset-tasks'">
	<FrameworkReference
	Update="Microsoft.NETCore.App"
	TargetingPackVersion="$(MicrosoftNETCoreAppRefPackageVersion)"
	RuntimeFrameworkVersion="$(MicrosoftNETCoreAppRuntimePackageVersion)" />
	</ItemGroup>

But with this PR, $(MicrosoftNETCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)')) is false:

• MicrosoftNETCoreAppRefPackageVersion is 9.0.0-alpha.1.23430.1
• _TargetFrameworkVersionWithoutV is 8.0

[elinor-fung]

@dsplaisted / @marcpopMSFT how does SDK usually handle updating major versions and targeting the consumed runtime version?

The retargeting for ASP.NET references has a similar condition:

sdk/Directory.Build.targets

Lines 56 to 63 in aabbd97

	<ItemGroupCondition="$(MicrosoftAspNetCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)'))">
	<KnownFrameworkReferenceUpdate="Microsoft.AspNetCore.App">
	<LatestRuntimeFrameworkVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</LatestRuntimeFrameworkVersion>
	<RuntimePackRuntimeIdentifiers>${SupportedRuntimeIdentifiers}</RuntimePackRuntimeIdentifiers>
	<TargetingPackVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</TargetingPackVersion>
	<DefaultRuntimeFrameworkVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</DefaultRuntimeFrameworkVersion>
	</KnownFrameworkReference>
	</ItemGroup>

[dsplaisted]

Now that the dependency flow is bringing in .NET 9 instead of .NET 8, the build doesn't have a version of .NET 8 to update the targeting to. I think the thing to do here is to update the stage 0 SDK to one that has a recent enough version of the runtime.

FYI for those not aware, here is where we are trying to keep track of the changes needed each time we update to a new TargetFramework: https://github.com/dotnet/sdk/blob/main/documentation/general/UpdateToNewTargetFramework.md Feel free to update it as appropriate.

[lewing]

@ViktorHofer @dotnet/domestic-cat please take a look

[baronfel]

@dsplaisted would you mind double-checking this and seeing if it matched what you were talking about?

[dsplaisted]

Yes, this matches what I expected. It might be better to use NuGetVersion instead of SemanticVersion. I'm not too sure of the differences between them, but the code I've seen has used NuGetVersion.

[marcpopMSFT]

latest change has us down to 34 test failures. @dotnet/source-build-internal @agocke@sbomer

1. Microsoft.NET.Sdk.BlazorWebAssembly.AoT.Tests.WasmAoTPublishIntegrationTest.AoT_Publish_WithExistingWebConfig_Works
   emcc : error : C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory ("C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a" was expected to be an input file, based on the commandline arguments provided) [C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\AoT_Publish_W---DA56BF44\blazorwasm\blazorwasm.csproj]
2. Microsoft.NET.Publish.Tests.GivenThatWeWantToPublishAnAotApp.NativeAotLib_errors_out_when_eventpipe_is_enabled
   Expected command to fail but it did not.
3. Source build is flagging the 8.0 downgrades I checked in to fix the System.Text.Json failure. Not sure what to do about this as it's meant to be temporary

Package IDs are:
Microsoft.Bcl.AsyncInterfaces.8.0.0-rc.1.23414.4
Microsoft.Extensions.DependencyModel.8.0.0-rc.1.23414.4
Microsoft.NET.HostModel.8.0.0-rc.1.23414.4```
There are a few other individual tests failures are unbuntu it looks like that also need to be looked into.

[elinor-fung]

Microsoft.NET.Publish.Tests.GivenThatWeWantToPublishAnAotApp.NativeAotLib_errors_out_when_eventpipe_is_enabled

Microsoft.DotNet.ILCompiler being used is now 8.0.0-rc.1.23414.4 - which is from before dotnet/runtime#90811 (main is using 8.0.0-rc.1.23421.3). Maybe related to the BundledVersions changes in this PR?

Side note: not the issue being hit in this PR, but that error is also being downgraded to a warning (dotnet/runtime#91715), so the test will also need to be updated when that change flows over.

[lewing]

I've updated the runtime flow to the most recent build. The wasm build is odd @maraf and @radical can you please take a look.

[elinor-fung]

C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory

Maybe the wasm error is the same as root cause as the native aot one - seems like the test environment gets constructed such that it is using older packages. As with Microsoft.DotNet.ILCompiler, the version of Microsoft.NETCore.App.Runtime.Mono.browser-wasm being used is an older version - 8.0.0-rc.1.23414.4 - which is before libmono-wasm-simd.a was added.

[radical]

C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory

This is because 9.0 targets are being used with a 8.0 runtime pack. I'm trying to reproduce this locally now.

[lewing]

Looks like we are down to NativeAOT publish failures now?

[marek-safar]

@sbomer@LakshanF could you help with resolving tests failures in AotStaticLibraryPublishWithEventPipe ?

[marek-safar]

@dotnet/source-build-internal could you please advise how to track where these prebuilts are coming from and how to version baseline-comparison.xml in 8.0 arcade for 9.0 main?

[MichaelSimons]

Is this intentionally incoherent with the other runtime dependencies? They are on version 9.0.0-alpha.1.23464.19 and sha a6c64c3c26417f579022e20cbcee992b4814ed2c. This is the source of the following source-build prebuilts that are being reported:

 <Usage Id="Microsoft.NETCore.DotNetAppHost" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json" />
<Usage Id="Microsoft.NETCore.DotNetAppHost" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json" />
<Usage Id="Microsoft.NETCore.DotNetHostResolver" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json" IsDirectDependency="true" />
<Usage Id="Microsoft.NETCore.DotNetHostResolver" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json" IsDirectDependency="true" />

[elinor-fung]

We actually removed Microsoft.NETCore.DotNetHostResolver in runtime. It looks like this repo is using it to grab hostfxr for Framework builds. I think it can use Microsoft.NETCore.App.Runtime.* packages - I'll take a look.

[MichaelSimons]

@dotnet/source-build-internal could you please advise how to track where these prebuilts are coming from and how to version baseline-comparison.xml in 8.0 arcade for 9.0 main?

I took a quick look. Here is what I did:

1. Reviewed the prebuilt baseline-comparison.xml.
2. Noted two classes of prebuilts as they come from two different project groupings.
3. First grouping is from src/artifacts/obj/Release/Sdks/Microsoft.NET.Sdk/tools/project.assets.json which when looking at the changes led me to this conclusion.
4. Second grouping is from src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json and src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json which led me to review the version of the referenced prebuilts in the versions.props and version.details.xml and noticed this incoherency.

[elinor-fung]

Second grouping from Microsoft.DotNet.MSBuildSdkResolver / Microsoft.DotNet.SdkResolver is resolved.

#35048 (comment) is all that is left.

[lewing]

@marcpopMSFT ping

[lewing]

Fix the 9.0.100 band in the emsdk transport package name

[lewing]

this may need additional tweaks to deal with the band versioning

[lewing]

Installer needs a bunch of updates as well once this lands

[jeffschwMSFT]

who is on point to either identifying the individual failures and farming out the work and/or handling them?

[mmitche]

@jeffschwMSFT There shouldn't be too much. This was the commit to switch to 8: 8119940

[lewing]

opened dotnet/arcade#14002 for future me

[lewing]

Looks like it is failing on rid resolution now @elinor-fung can you take a look?

[elinor-fung]

The built tests are configured to run on a runtime from before dotnet/docs#36466 for some reason.

If I build main, the runtimeconfig for the Microsoft.NET.Build.Tests has the runtime version corresponding to Version.props/Version.Details.xml:

 "runtimeOptions": {
"tfm": "net8.0",
"rollForward": "Major",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "8.0.0-rc.1.23421.3"
},

But from this branch, it has:

 "runtimeOptions": {
"tfm": "net8.0",
"rollForward": "Major",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "8.0.0-preview.7.23375.6"
},

I'm not sure why yet - cc @dsplaisted in case it is something obvious to you

[elinor-fung]

This is what does the updating to the runtime version that gets used by tests:

sdk/Directory.Build.targets

Lines 46 to 54 in aabbd97

	<!-- Update KnownFrameworkReferences to target the right version of the runtime -->
	<ItemGroupCondition="'$(TargetFrameworkIdentifier)' == '.NETCoreApp'
	and $(MicrosoftNETCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)'))
	and '$(MSBuildProjectName)' != 'toolset-tasks'">
	<FrameworkReference
	Update="Microsoft.NETCore.App"
	TargetingPackVersion="$(MicrosoftNETCoreAppRefPackageVersion)"
	RuntimeFrameworkVersion="$(MicrosoftNETCoreAppRuntimePackageVersion)" />
	</ItemGroup>

But with this PR, $(MicrosoftNETCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)')) is false:

• MicrosoftNETCoreAppRefPackageVersion is 9.0.0-alpha.1.23430.1
• _TargetFrameworkVersionWithoutV is 8.0

[elinor-fung]

@dsplaisted / @marcpopMSFT how does SDK usually handle updating major versions and targeting the consumed runtime version?

The retargeting for ASP.NET references has a similar condition:

sdk/Directory.Build.targets

Lines 56 to 63 in aabbd97

	<ItemGroupCondition="$(MicrosoftAspNetCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)'))">
	<KnownFrameworkReferenceUpdate="Microsoft.AspNetCore.App">
	<LatestRuntimeFrameworkVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</LatestRuntimeFrameworkVersion>
	<RuntimePackRuntimeIdentifiers>${SupportedRuntimeIdentifiers}</RuntimePackRuntimeIdentifiers>
	<TargetingPackVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</TargetingPackVersion>
	<DefaultRuntimeFrameworkVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</DefaultRuntimeFrameworkVersion>
	</KnownFrameworkReference>
	</ItemGroup>

[dsplaisted]

Now that the dependency flow is bringing in .NET 9 instead of .NET 8, the build doesn't have a version of .NET 8 to update the targeting to. I think the thing to do here is to update the stage 0 SDK to one that has a recent enough version of the runtime.

FYI for those not aware, here is where we are trying to keep track of the changes needed each time we update to a new TargetFramework: https://github.com/dotnet/sdk/blob/main/documentation/general/UpdateToNewTargetFramework.md Feel free to update it as appropriate.

[lewing]

@ViktorHofer @dotnet/domestic-cat please take a look

[baronfel]

@dsplaisted would you mind double-checking this and seeing if it matched what you were talking about?

[dsplaisted]

Yes, this matches what I expected. It might be better to use NuGetVersion instead of SemanticVersion. I'm not too sure of the differences between them, but the code I've seen has used NuGetVersion.

[marcpopMSFT]

latest change has us down to 34 test failures. @dotnet/source-build-internal @agocke@sbomer

1. Microsoft.NET.Sdk.BlazorWebAssembly.AoT.Tests.WasmAoTPublishIntegrationTest.AoT_Publish_WithExistingWebConfig_Works
   emcc : error : C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory ("C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a" was expected to be an input file, based on the commandline arguments provided) [C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\AoT_Publish_W---DA56BF44\blazorwasm\blazorwasm.csproj]
2. Microsoft.NET.Publish.Tests.GivenThatWeWantToPublishAnAotApp.NativeAotLib_errors_out_when_eventpipe_is_enabled
   Expected command to fail but it did not.
3. Source build is flagging the 8.0 downgrades I checked in to fix the System.Text.Json failure. Not sure what to do about this as it's meant to be temporary

Package IDs are:
Microsoft.Bcl.AsyncInterfaces.8.0.0-rc.1.23414.4
Microsoft.Extensions.DependencyModel.8.0.0-rc.1.23414.4
Microsoft.NET.HostModel.8.0.0-rc.1.23414.4```
There are a few other individual tests failures are unbuntu it looks like that also need to be looked into.

[elinor-fung]

Microsoft.NET.Publish.Tests.GivenThatWeWantToPublishAnAotApp.NativeAotLib_errors_out_when_eventpipe_is_enabled

Microsoft.DotNet.ILCompiler being used is now 8.0.0-rc.1.23414.4 - which is from before dotnet/runtime#90811 (main is using 8.0.0-rc.1.23421.3). Maybe related to the BundledVersions changes in this PR?

Side note: not the issue being hit in this PR, but that error is also being downgraded to a warning (dotnet/runtime#91715), so the test will also need to be updated when that change flows over.

[lewing]

I've updated the runtime flow to the most recent build. The wasm build is odd @maraf and @radical can you please take a look.

[elinor-fung]

C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory

Maybe the wasm error is the same as root cause as the native aot one - seems like the test environment gets constructed such that it is using older packages. As with Microsoft.DotNet.ILCompiler, the version of Microsoft.NETCore.App.Runtime.Mono.browser-wasm being used is an older version - 8.0.0-rc.1.23414.4 - which is before libmono-wasm-simd.a was added.

[radical]

C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory

This is because 9.0 targets are being used with a 8.0 runtime pack. I'm trying to reproduce this locally now.

[lewing]

Looks like we are down to NativeAOT publish failures now?

[marek-safar]

@sbomer@LakshanF could you help with resolving tests failures in AotStaticLibraryPublishWithEventPipe ?

[marek-safar]

@dotnet/source-build-internal could you please advise how to track where these prebuilts are coming from and how to version baseline-comparison.xml in 8.0 arcade for 9.0 main?

[MichaelSimons]

Is this intentionally incoherent with the other runtime dependencies? They are on version 9.0.0-alpha.1.23464.19 and sha a6c64c3c26417f579022e20cbcee992b4814ed2c. This is the source of the following source-build prebuilts that are being reported:

 <Usage Id="Microsoft.NETCore.DotNetAppHost" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json" />
<Usage Id="Microsoft.NETCore.DotNetAppHost" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json" />
<Usage Id="Microsoft.NETCore.DotNetHostResolver" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json" IsDirectDependency="true" />
<Usage Id="Microsoft.NETCore.DotNetHostResolver" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json" IsDirectDependency="true" />

[elinor-fung]

We actually removed Microsoft.NETCore.DotNetHostResolver in runtime. It looks like this repo is using it to grab hostfxr for Framework builds. I think it can use Microsoft.NETCore.App.Runtime.* packages - I'll take a look.

[MichaelSimons]

@dotnet/source-build-internal could you please advise how to track where these prebuilts are coming from and how to version baseline-comparison.xml in 8.0 arcade for 9.0 main?

I took a quick look. Here is what I did:

1. Reviewed the prebuilt baseline-comparison.xml.
2. Noted two classes of prebuilts as they come from two different project groupings.
3. First grouping is from src/artifacts/obj/Release/Sdks/Microsoft.NET.Sdk/tools/project.assets.json which when looking at the changes led me to this conclusion.
4. Second grouping is from src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json and src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json which led me to review the version of the referenced prebuilts in the versions.props and version.details.xml and noticed this incoherency.

[elinor-fung]

Second grouping from Microsoft.DotNet.MSBuildSdkResolver / Microsoft.DotNet.SdkResolver is resolved.

#35048 (comment) is all that is left.

[lewing]

@marcpopMSFT ping

[lewing]

Fix the 9.0.100 band in the emsdk transport package name

[lewing]

this may need additional tweaks to deal with the band versioning

[lewing]

Installer needs a bunch of updates as well once this lands

[jeffschwMSFT]

who is on point to either identifying the individual failures and farming out the work and/or handling them?

[mmitche]

@jeffschwMSFT There shouldn't be too much. This was the commit to switch to 8: 8119940

[lewing]

opened dotnet/arcade#14002 for future me

[lewing]

Looks like it is failing on rid resolution now @elinor-fung can you take a look?

[elinor-fung]

The built tests are configured to run on a runtime from before dotnet/docs#36466 for some reason.

If I build main, the runtimeconfig for the Microsoft.NET.Build.Tests has the runtime version corresponding to Version.props/Version.Details.xml:

 "runtimeOptions": {
"tfm": "net8.0",
"rollForward": "Major",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "8.0.0-rc.1.23421.3"
},

But from this branch, it has:

 "runtimeOptions": {
"tfm": "net8.0",
"rollForward": "Major",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "8.0.0-preview.7.23375.6"
},

I'm not sure why yet - cc @dsplaisted in case it is something obvious to you

[elinor-fung]

This is what does the updating to the runtime version that gets used by tests:

sdk/Directory.Build.targets

Lines 46 to 54 in aabbd97

	<!-- Update KnownFrameworkReferences to target the right version of the runtime -->
	<ItemGroupCondition="'$(TargetFrameworkIdentifier)' == '.NETCoreApp'
	and $(MicrosoftNETCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)'))
	and '$(MSBuildProjectName)' != 'toolset-tasks'">
	<FrameworkReference
	Update="Microsoft.NETCore.App"
	TargetingPackVersion="$(MicrosoftNETCoreAppRefPackageVersion)"
	RuntimeFrameworkVersion="$(MicrosoftNETCoreAppRuntimePackageVersion)" />
	</ItemGroup>

But with this PR, $(MicrosoftNETCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)')) is false:

• MicrosoftNETCoreAppRefPackageVersion is 9.0.0-alpha.1.23430.1
• _TargetFrameworkVersionWithoutV is 8.0

[elinor-fung]

@dsplaisted / @marcpopMSFT how does SDK usually handle updating major versions and targeting the consumed runtime version?

The retargeting for ASP.NET references has a similar condition:

sdk/Directory.Build.targets

Lines 56 to 63 in aabbd97

	<ItemGroupCondition="$(MicrosoftAspNetCoreAppRefPackageVersion.StartsWith('$(_TargetFrameworkVersionWithoutV)'))">
	<KnownFrameworkReferenceUpdate="Microsoft.AspNetCore.App">
	<LatestRuntimeFrameworkVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</LatestRuntimeFrameworkVersion>
	<RuntimePackRuntimeIdentifiers>${SupportedRuntimeIdentifiers}</RuntimePackRuntimeIdentifiers>
	<TargetingPackVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</TargetingPackVersion>
	<DefaultRuntimeFrameworkVersion>$(MicrosoftAspNetCoreAppRefPackageVersion)</DefaultRuntimeFrameworkVersion>
	</KnownFrameworkReference>
	</ItemGroup>

[dsplaisted]

Now that the dependency flow is bringing in .NET 9 instead of .NET 8, the build doesn't have a version of .NET 8 to update the targeting to. I think the thing to do here is to update the stage 0 SDK to one that has a recent enough version of the runtime.

FYI for those not aware, here is where we are trying to keep track of the changes needed each time we update to a new TargetFramework: https://github.com/dotnet/sdk/blob/main/documentation/general/UpdateToNewTargetFramework.md Feel free to update it as appropriate.

[lewing]

@ViktorHofer @dotnet/domestic-cat please take a look

[baronfel]

@dsplaisted would you mind double-checking this and seeing if it matched what you were talking about?

[dsplaisted]

Yes, this matches what I expected. It might be better to use NuGetVersion instead of SemanticVersion. I'm not too sure of the differences between them, but the code I've seen has used NuGetVersion.

[marcpopMSFT]

latest change has us down to 34 test failures. @dotnet/source-build-internal @agocke@sbomer

1. Microsoft.NET.Sdk.BlazorWebAssembly.AoT.Tests.WasmAoTPublishIntegrationTest.AoT_Publish_WithExistingWebConfig_Works
   emcc : error : C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory ("C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a" was expected to be an input file, based on the commandline arguments provided) [C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b\AoT_Publish_W---DA56BF44\blazorwasm\blazorwasm.csproj]
2. Microsoft.NET.Publish.Tests.GivenThatWeWantToPublishAnAotApp.NativeAotLib_errors_out_when_eventpipe_is_enabled
   Expected command to fail but it did not.
3. Source build is flagging the 8.0 downgrades I checked in to fix the System.Text.Json failure. Not sure what to do about this as it's meant to be temporary

Package IDs are:
Microsoft.Bcl.AsyncInterfaces.8.0.0-rc.1.23414.4
Microsoft.Extensions.DependencyModel.8.0.0-rc.1.23414.4
Microsoft.NET.HostModel.8.0.0-rc.1.23414.4```
There are a few other individual tests failures are unbuntu it looks like that also need to be looked into.

[elinor-fung]

Microsoft.NET.Publish.Tests.GivenThatWeWantToPublishAnAotApp.NativeAotLib_errors_out_when_eventpipe_is_enabled

Microsoft.DotNet.ILCompiler being used is now 8.0.0-rc.1.23414.4 - which is from before dotnet/runtime#90811 (main is using 8.0.0-rc.1.23421.3). Maybe related to the BundledVersions changes in this PR?

Side note: not the issue being hit in this PR, but that error is also being downgraded to a warning (dotnet/runtime#91715), so the test will also need to be updated when that change flows over.

[lewing]

I've updated the runtime flow to the most recent build. The wasm build is odd @maraf and @radical can you please take a look.

[elinor-fung]

C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory

Maybe the wasm error is the same as root cause as the native aot one - seems like the test environment gets constructed such that it is using older packages. As with Microsoft.DotNet.ILCompiler, the version of Microsoft.NETCore.App.Runtime.Mono.browser-wasm being used is an older version - 8.0.0-rc.1.23414.4 - which is before libmono-wasm-simd.a was added.

[radical]

C:\h\w\B1C3097B\t\dotnetSdkTests\ij4x4eyn.d0b.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\8.0.0-rc.1.23414.4\runtimes\browser-wasm\native\libmono-wasm-simd.a: No such file or directory

This is because 9.0 targets are being used with a 8.0 runtime pack. I'm trying to reproduce this locally now.

[lewing]

Looks like we are down to NativeAOT publish failures now?

[marek-safar]

@sbomer@LakshanF could you help with resolving tests failures in AotStaticLibraryPublishWithEventPipe ?

[marek-safar]

@dotnet/source-build-internal could you please advise how to track where these prebuilts are coming from and how to version baseline-comparison.xml in 8.0 arcade for 9.0 main?

[MichaelSimons]

Is this intentionally incoherent with the other runtime dependencies? They are on version 9.0.0-alpha.1.23464.19 and sha a6c64c3c26417f579022e20cbcee992b4814ed2c. This is the source of the following source-build prebuilts that are being reported:

 <Usage Id="Microsoft.NETCore.DotNetAppHost" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json" />
<Usage Id="Microsoft.NETCore.DotNetAppHost" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json" />
<Usage Id="Microsoft.NETCore.DotNetHostResolver" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json" IsDirectDependency="true" />
<Usage Id="Microsoft.NETCore.DotNetHostResolver" Version="9.0.0-alpha.1.23455.1" File="src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json" IsDirectDependency="true" />

[elinor-fung]

We actually removed Microsoft.NETCore.DotNetHostResolver in runtime. It looks like this repo is using it to grab hostfxr for Framework builds. I think it can use Microsoft.NETCore.App.Runtime.* packages - I'll take a look.

[MichaelSimons]

@dotnet/source-build-internal could you please advise how to track where these prebuilts are coming from and how to version baseline-comparison.xml in 8.0 arcade for 9.0 main?

I took a quick look. Here is what I did:

1. Reviewed the prebuilt baseline-comparison.xml.
2. Noted two classes of prebuilts as they come from two different project groupings.
3. First grouping is from src/artifacts/obj/Release/Sdks/Microsoft.NET.Sdk/tools/project.assets.json which when looking at the changes led me to this conclusion.
4. Second grouping is from src/artifacts/obj/Microsoft.DotNet.MSBuildSdkResolver/project.assets.json and src/artifacts/obj/Microsoft.DotNet.SdkResolver/project.assets.json which led me to review the version of the referenced prebuilts in the versions.props and version.details.xml and noticed this incoherency.

[elinor-fung]

Second grouping from Microsoft.DotNet.MSBuildSdkResolver / Microsoft.DotNet.SdkResolver is resolved.

#35048 (comment) is all that is left.

[lewing]

@marcpopMSFT ping