Move to building with the 9.0 SDK and move our ToolCurrent TFM to 9.0

[jkoritzinsky]

Unblocks #95904

[ghost]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

Issue Details

---

null

Author:	jkoritzinsky
Assignees:	-
Labels:	area-Infrastructure
Milestone:	9.0.0

[am11]

Looks like src/tools/illink/test/Trimming.Tests.Shared/PathUtilities.cs can be simplified to:

        public static class PathUtilities
        {
-#if NET8_0
-               public const string TFMDirectoryName = "net8.0";
-#elif NET7_0
-               public const string TFMDirectoryName = "net7.0";
-#elif NET6_0
-               public const string TFMDirectoryName = "net6.0";
-#elif NET5_0
-               public const string TFMDirectoryName = "net5.0";
-#elif NETCOREAPP3_0
-               public const string TFMDirectoryName = "netcoreapp3.0";
-#elif NET471
+#if NET471
                public const string TFMDirectoryName = "net471";
 #else
-#error "Unknown TFM"
+               public static readonly string TFMDirectoryName = $"net{Environment.Version.Major}.{Environment.Version.Minor}";
 #endif

(dropping netcoreapp3.0)

[ViktorHofer]

@sbomer @vitek-karas can you please help with the linker test failures?

[ViktorHofer]

@mikem8361 can you please take a look at the failing CustomAttributeDelete test in System.Runtime.Loader? It's this line: https://github.com/jkoritzinsky/runtime/blob/9461f4b5bd036005f37e78516c48b13396f76750/src/libraries/System.Runtime.Loader/tests/ApplyUpdateTest.cs#L241

[mikem8361]

I haven't work on ENC/hot reload/loader in 2 years. I assume some .NET 9 loader change broke this test. @mikelle-rogers might have an idea of what broken.

[ericstj]

I see @akoeplinger is updating dotnet/hotreload-utils#348. Maybe he's already onto what fix is needed here?

My best guess was that the hot reload diff somehow broke custom attribute type lookup. Tried to debug, but these tests don't like that

Not sure how to inspect the content of the hot-reload delta, or try to apply it and inspect the final assembly. My guess is some problem there. It's odd that it's only this one test failing.

If @akoeplinger's fix to the hot reload tools doesn't resolve this, I recommend we just file an issue for the hot-reload owners to fix.

Edit: after closer inspection - probably that change is unrelated. Still not sure what's going on that would cause this hot reload test to start failing.

[trylek]

I'm afraid I cannot add much more to what Eric has already discovered. Binary diffing of the dmeta file shows a "larger" diff for CustomAttributeDelete.dll.1.dmeta between the runtime repo without and with this change compared to the other dmeta files like CustomAttributeUpdate.dll.1.dmeta leading me to suspect that the tool used to generate the metadata delta files has a new bug in encoding the custom attribute deletion / replacement (the offending case is supposed to delete two attributes and add a new one) but I have no idea where its source code sits and / or how to dump the contents of the dmeta file that would let me investigate this further.

[akoeplinger]

Updating to latest hotreload-utils and newer SDK fixed this locally, let's see what CI says.

[ViktorHofer]

I simplified the path expectations logic in the linker tests but had to push individual commits (and manually) as my codespace doesn't have permissions to push to this fork.

[ViktorHofer]

@radical please take a look at all the wasm/wasi failures

[radical]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ViktorHofer]

Should this RID addition be up-streamed into dotnet/sdk?

[radical]

wasi-wasm is only supported with the workload right now, so we add that as part of the workload. And adding here for in-tree builds. So, upstreaming it is not needed right now.

[radical]

I have been trying to debug the last remaining failures on WBT, and it seems to be down to dotnet new wasmbrowser - the process never seems to end.

...
      [5734] [] [2024-01-12 03:34:50.792] [Debug] [Microsoft.TemplateEngine.Edge.Template.TemplateCreator] => [Execute] => [Template content generation]: Template content generation finished, took 71 ms
      [5734] [] The template "WebAssembly Browser App" was created successfully.
      [5734] []
      [5734] [] [2024-01-12 03:34:50.795] [Debug] [Template Engine] => [Execute]: Execute finished, took 234 ms--------------------

.. and we wait for 3mins but the process never seems to exit.

[radical]

I can reproduce this only on CI. And it does not happen for the first few times/tests.

[radical]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ViktorHofer]

• Two runtime-wasm legs timed out, even after retrying. This looks related to an AzDO machine pool issue (logs mention the machines got purged).
• An issue already exists for the libraries test failure.

I don't think that any of those issues block merging the PR. Given that we need to get this in ASAP for being able to ship .NET 9 Preview 1, I'm merging this in now.