Work that needs to happen for .NET 5 TFMs

[terrajobst]

The spec for .NET 5 TFMs can be found here.

Runtime/SDK

• Ensure SDK explodes .NET 5 TargetFramework into TargetFramework* and TargetPlatform* properties
• Make the build fail when a TFM with an unsupported OS or OS version is being used
• Update RIDs for Xamarin platforms
• Add preprocessor symbols for OS
• Handle new TFMs in runtimeconfig and host
• Produce a warning when a net5.0 project references netcoreapp3.1 (or earlier) with WPF/WinForms
• Cut
  • Add shared framework for Xamarin platforms
  • Add SDK-style build support for Xamarin

NuGet

• net5 tfm: framework precedence rules
• net5 tfm: produce error when missing TPV
• net5 tfm: "hydrating" empty TargetPlatformVersions
• net5.0 VS APIs
• With multi targeted projects, NuGet should read the target framework related information from the inner build.
• NuGet pack should catch incorrect omitting of the dot in version numbers
• Cut
  • Make NuGet understand that the existing Xamarin TFMs can be installed into the new net5.0-xxx TFMs (Xamarin is pushed to .NET 6)
  • Fail pack when packing equivalent TFMs like net5.0-ios and net5.0-ios13.0 (this state is impossible now)
  • Produce a warning when a project consumes a library with a higher TargetPlatformMinVersion (handled by analyzer)
  • net5 tfm: TargetPlatformMinVersion in packed nuspec (handled by analyzer)
• Future
  • Add a TFM for Unity's DOTS profile

MSBuild

• Allow TFM/TPM checks in a concise, understandable way

Project System

• Pass the correct information to NuGet restore, specifically TFI, TFV, TPI, TPV

@rainersigwald @dsplaisted @rrelyea @ericstj @ViktorHofer Please help me complete the list of items. Also, we would make sure that each item is linked to a corresponding GitHub issue.

[marek-safar]

Add shared framework for Xamarin platforms

What do you mean by that?

Add SDK-style build support for Xamarin

Don’t think this should be here, it’s not required for runtime but build on top of that as other workloads

[vitek-karas]

Should add whatever work comes out of this issue: #34033

[hypeartist]

Is that related: https://github.com/dotnet/runtime/issues/34060 ?

[terrajobst]

Add shared framework for Xamarin platforms

What do you mean by that?

We need to figure out how a project targeting say net5.0-ios13.0 references the platform, which includes both the BCL as well as the Xamarin specific bits on top. Implicit PackageReference? FrameworkReference?

Add SDK-style build support for Xamarin

Don’t think this should be here, it’s not required for runtime but build on top of that as other workloads

The point of this issue to group all the work that is happening for bringer this work to life; the point isn't to design the items themselves. @mhutch, do you want to file a similar uber item for Xamarin work? It should track things like the SDK style project, how the framework is being referenced etc. I would just link this one instead.

[danmoseley]

cc @ViktorHofer

[steveisok]

+1 to the uber item for Xamarin.

[dsplaisted]

@terrajobst Additional item for NuGet (underway now):

• Update NuGet TargetFramework parsing to parse TargetPlatformIdentifier and TargetPlatformVersion

[danmoseley]

@dsplaisted do you see any work here for the Mono or Libraries teams? My impression is no -- this is what I understand from @terrajobst last week as well (the "Runtime/SDK" section seems all SDK except the last one which is @vitek-karas ). Do I read that right?

[steveisok]

• Add shared framework for Xamarin platforms

@terrajobst We're adding runtime packs for Microsoft.NETCore.App.Runtime.<Mobile RID> and Xamarin iOS/Android. What do you mean by 'shared framework'? Did you mean the same thing? I could be misunderstanding the broader view.

[danmoseley]

Linking the SDK epic dotnet/sdk#11165

[zkat]

Linking the NuGet epic: NuGet/Home#9090

[plamploika]

Sorry for the intrusion and maybe a stupid question but,
I read this article and I was surprised by the following sentence: "Miguel is building Baby Shark, a popular iOS application. He started with .NET that supported iOS 13 but Apple just released iOS 14. He downloads the updated version of the .NET 5 SDK which now also includes support for iOS 14."
Does this mean that support and bindings for all platforms will ship together .net 5 sdk? Is it possible to ship support and bindings separately, for example through a nuget?
It would bring the following benefits:

• smaller .net 5 sdk size. For example, I’m a web developer and I will never develop for mobile platforms, so I don’t need support for android and ios
• updating ios will result in updating the nuget-package, but not .net 5 sdk. For example, if a new ios update is released, the developer needs to update the nuget-package with bindings that will be released quickly, rather than waiting for the platform update

[svick]

@plamploika As far as I can tell, the plan is to distribute support for iOS and similar platforms separate from the SDK, using a new concept called "workload".

[plamploika]

@svick, yes, it is great
But the problem remains with the long wait for the new version of the framework, which includes bundles for the new version of the OS.

I'm also interested in what will happen to a new version of bindings after release of a new version of the .net. For example, in the future, where there is .net9.0, the Apple provides iOS 16. Will .net5.0 be updated to support the bindings for iOS (in case I do not want to update the platform, but want to use the new features of iOS)?

Imho, separation contributes to general simplification: for example, you can leave only net5.0 tfm and install additional bindings through a nuget, if necessary

[svick]

@plamploika

But the problem remains with the long wait for the new version of the framework, which includes bundles for the new version of the OS.

I don't think you will have to wait long. From the document I linked above:

Workloads will be updatable. The SDK will include a mechanism to discover if a workload manifest pack has been updated. An updated manifest could represent bug fixes or new features (like updated bindings for an operating system update). If a manifest has been updated, the user will be notified, and have the opportunity to acquire the new version. Updates will not be automatic.

---

I'm also interested in what will happen to a new version of bindings after the release of the new version of the .net. For example, in the future, where there is .net9.0, the Apple provides iOS 16. Will .net5.0 be updated to support the bindings for iOS (in case I do not want to update the platform, but want to use the new features of iOS)?

If the release schedule proceeds according to the current plan, .Net 9.0 will be released in 2024. By then, .Net 5.0 (which is not an LTS release) will be long out of support, and .Net 6.0 (which is LTS) will just slip out of support. So I don't think those will be updated with new iOS bindings at that point.

---

Imho, separation contributes to general simplification

It's definitely not simpler to develop, if MS has to make new code compatible with many old frameworks.

[plamploika]

@svick, thanks for the answers, but I would like to clarify something else.
OS-bindings can be delivered through a special moniker or nuget.

It's definitely not simpler to develop, if MS has to make new code compatible with many old frameworks.

So, how does delivering bindings through nuget lead to code incompatibility?

[danmoseley]

@terrajobst can you confirm there's no remaining 5.0 work on platform (ie., dotnet/runtime) here? That seems to be the case. I'd like to know we're done at that layer.

[joperezr]

ping @terrajobst 😃

Can we consider this done for 5.0 in terms of dotnet/runtime side?

[terrajobst]

Confirmed

[ericstj]

@terrajobst is there any work remaining here for any repos in 5.0 or should we close this?

[danmoseley]

@terrajobst ?

[zkat]

NuGet/Home#9215 is still open, as is NuGet/Home#9441, and we're still having discussions on how exactly to fix them, but they're relatively minor and imo shouldn't block things?

[danmoseley]

If we have open issues for the last remaining work then we should close this epic issue as it is no longer useful...

[danmoseley]

@zkat any objection to closing this? Are those appropriately tagged so they won't get lost for 5.0?

[ericstj]

Ping @zkat @terrajobst -- trying to close down active issues for 5.0 and need to understand if this needs to remain open.

[terrajobst]

I'm closing this as the only remaining work is in NuGet and that work is in-progress.

[danmoseley]

Removing Epic so it's not pulling active children into the themes tree.