Main branch net10.0 transition status tracking

[marcpopMSFT]

Current state

• main branch
  • open
  • Runtime flows have been merged
  • Watch scenarios/tests are still impacted
• 9.0.1xx
  • In approval mode. All non-infra changes must go through tactics and get approval.
  • High risk or breaking changes should wait for main.
• 9.0.2xx
  • Open for all feature work

main branch has been rebranded to 10.0.100-alpha and now has the 10.0 version of all runtimes
Some watch tests and template tests have been temporarily disabled.
.NET SDK is now targeting net10.0 as the TFM. All templates have been updated as well.

Process
https://github.com/dotnet/sdk/blob/main/documentation/general/UpdateToNewTargetFramework.md

• Update branding (complete)
• Add net10 framework references (complete)
• Flow net10 runtimes
• Update global.json
• Retarget the sdk to net10.0
• Retarget default templates to target net10.0
• Unwind any changes made during the transition (as tracked below) <-- we are here

The history of changes we've made so far:

• Alpha Branding #42743
  • pin template versions
  • disable format source build tests
  • Disable Tests Failing Due to Initial net10.0 Branding #42850
• Add net10.0 known framework references #42969
• Merge the net10 runtime, aspnetcore, windowsdesktop, and arcade codeflows #43070
  • Unwind prebuilt changes: Merge the net10 runtime, aspnetcore, windowsdesktop, and arcade codeflows #43070 (comment)
  • Unwind Merge the net10 runtime, aspnetcore, windowsdesktop, and arcade codeflows #43070 (comment)
  • Re-enable repo source-build leg https://github.com/dotnet/sdk/pull/43070/files#diff-fb7d8d37fd9e28ca688fd102422af3e1d1df13a50d7f2deb2e145aa5ef449057R299-R305. Requires that the SDK support .NET 10
  • Remove pinned attributes on dependencies in SDK. https://github.com/dotnet/sdk/pull/43070/files#diff-fb62e94a1d6f29f863e3d0a22aa38269f6cd1d7f03b109dc06e2cbf2548b86d3R140. Requires that the projects that use these deps target net10, which generally requires a net10 supporting SDK.
  • Restore original source-build build graph order (https://github.com/dotnet/sdk/pull/43070/files#diff-dc4355ab9132de03a6db3b02d5a013b251465766eda43193f39a8521673c3b6dR23). Requires a net10 bootstrap SDK.
  • Reenable source build smoke tests (https://github.com/dotnet/sdk/pull/43070/files#diff-e24a200b5f2578020786aef4fe81432fa52ec81a0ea5570dc82a653e62f20b93R23)
  • Reenable unified build scenario tests https://github.com/dotnet/sdk/pull/43070/files#diff-bad2cef491ccdacfa53d75caf6204ef2c781d2e27263283adc5ac4d5f17d6c02R6. Requires that the SDK support net10. Maybe also requires that scenario-tests target net10?
• Update the sdk target to net10.0 #43015

[WeihanLi]

Have a question about the target framework, currently, the SDK supports net8, would the SDK drop the support? Since net10 may conflict between net10.0 and netfx 1.0

[huoyaoyuan]

Since net10 may conflict between net10.0 and netfx 1.0

I think we will keep compatibility and force the usage of net10.0 instead of net10. This was mentioned in the initial TFM design:
https://github.com/dotnet/designs/blob/main/accepted/2020/net5/net5.md#what-about-net-10

[mmitche]

Suggestions and learnings from the process of getting the net10 runtimes into the SDK:

• Reduce the number of forcing functions in the updates. We want to be able to upgrade parts of the stack without doing the whole. The best example of this is that when runtime switches to target net10, it stops producing net9 assets for some key packages. These include the internal runtime shared framework transport packages (Microsoft.Internal.AspNetCore). When those flow into the VMR or downstream to aspnetcore, they force aspnetcore to upgrade its TFM. This means that we have to combine all the shared frameworks in the same SDK PR, and can't work incrementally.
• When repos move to a new TFM, they should not immediately remove support for the old TFM for any packages that normally single target until all downstream consumers who don't use KnownFrameworkRef (e.g. SDK) and/or can't move forward their TFM. For instance, aspnetcore single targets some OOB packages. These should temporarily multi-target until downstream projects can retarget to the new TFM. This would ease flow into the SDK, then allow the SDK to support a new TFM. At that point, the multi-targeted packages can move to single-targeting the new TFM.
• Add functionality to arcade to target frameworks yet unsupported by the SDK - KnownFrameworkReference is commonly used in some repos, but not in all. This should be standard functionality available from arcade for use by repos above runtime. It should cover more than just the framework ref. It should cover crossgen, ilc, etc. etc.
• Temporarily reorder the build graph if need be - Source build may need to temporarily need to reorder the build graph so that tooling repos can continue to target the previous TFM. This might show up as roslyn failing to run the syntax source generator. I think this is typically becuase the source generator will be moved to target net10 automatically, but the SDK that is running will only support net9.

[mmitche]

dotnet/arcade#15121

[agocke]

The best example of this is that when runtime switches to target net10, it stops producing net9 assets for some key packages

Let's go farther. I don't want runtime to move first anymore. Up stack needs to go first. But runtime needs to do a lot of stuff, so upstack needs to take it as a high priority to start work immediately once we snap.

[mmitche]

@agocke I don't think upstack can go first, because without the net10 shared frameworks available, upstack can't move to net10.

[agocke]

What's the minimum that's needed from runtime? Can we move only that?

[mmitche]

Need shared frameworks and OOBs to support the netN+1 TFM.

I think it really comes down to runtime needing to support the new TFM across all assets that are consumed by downstream shared framework/sdk repos without removing support for the old TFM for any OOBs/transport packages until downstream has moved. This is normally the case for OOBs, but some transport packages swap N for N+1.

[akoeplinger]

Wouldn't most of this stop being a problem once we can make the changes across repos in the VMR in a single PR?

[mmitche]

Wouldn't most of this stop being a problem once we can make the changes across repos in the VMR in a single PR?

Maybe. It's probably more efficient to make those changes all at once. But the amount of work (code changes) probably doesn't change in a material way. It may be still easier to work incrementally than trying to do the update in one mega PR.

[akoeplinger]

It may be still easier to work incrementally than trying to do the update in one mega PR.

I kinda doubt it, the biggest issue is getting the product into a consistent state and that is much easier in a single PR. But we'll see 😄