Very disappoint on the .net 5 TFM names

[John0King]

this is the doc. https://github.com/dotnet/designs/blob/main/accepted/2020/net5/net5.md with .net 5 you guys said it's the journey to one .net, after I read the article I find that it's a big big lie. .net5-ios ,.net5-ios14 , so .net is not the platform , the OS is , and so why not use swift and object-c , they never need a OS to support there language or the language update to support OS Version. let's see what we know here.

1. to support new OS , we just need to write binding to the native library, which do not have any thing related with .net it self.(.net 1 is support p/invoke to native)
2. OS feature is just things like Console.ReadLine() or Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)

so you tel me why IOS14 is different than IOS 13? and what about the older OS? both IOS and Android, so people come to .net 5 for what ? for drop users that do not want to upgrade their OS because they have a old device ?

android have success is because they only add jvm to andorid no java BCL stuff, now you can still target the latest andorid 11 and support Android 4 toooooo ! and IOS even better, they use native language . all there work is doing for onething, you can just write app for latest OS and will work on older version OS too.

Xamarin/Unity team respect that , but sadly net team don't . 😞

Today using .Net have risk （base on history）

1. start using .net now and want to upgrade to newer .Net but your Server OS, or Client OS version is a big problem (after all, .net is the first language that drop support win xp , when people try upgread .net 4 to .net 4.5)
2. runtime/framework/OS as a dependency the customer machine may not install (for that , look at js, they never let js engine or electron dependency be cumbersome)
3. always have some new tech, but not for long ,and not be popular in developer community（that means you can get less help than other languge）, from webform->mvc->core mvc -> razor page -> blazor; or winform->wpf->uwp , that mean you need lean more but do less.

I write this because I love C# , I really hope .net not go to the wrong way.

and by the way , if oneday thire is a native C# (static library support and drop vm) that will be great.

[John0King]

What I try to say is that https://github.com/dotnet/designs/issues/136#issuecomment-674996951 saids, we are on the road to the One .Net , I hope that is not just a slogan but should with actual deeds. the .net5-ios14 .net5-ios15 or android level well once again make several subset of .net 5 , and that is not the One .Net.

from years ago, that .net core 3.x was in develop, and microsoft make a decision to bring asp.net core (a framework, a app dependency) into the BCL, I wasn't happy because I can bring asp.net core 2 to xamarin.andorid , but I can not bring asp.net core 3.x to Xamarin. And from that time, Microsoft start it's journey to bring everything that developed by microsoft into BCL.

I think the BCL/Clr should only have code to run and build .net apps, it should be small size and stable.

Let's face the actual problem:

App development Mode (developed by Microsoft and third party)

1. Asp.net Core
2. WPF
3. WinForm
4. Android
5. IOS
6. UWP
7. Mono
8. Tizen (develped by SamSung, Supported by Xamarin)
9. Unity
10. Stride ((formerly Xenko)
11. MonoGame
12. GoDot
13. Wave Engine
14. CRYENGINE
15. Avalonia
16. [...]

Ask: Will each of them have Target Framework Name ? .net5-Tizen1 ,.net5-Tizen2 , .net5-avalonia The answer is : No, so what make .net5-ios and .net5-android so special ? Does the answer be that they the developed by DotNet Team ?

I think in .Net we can have go to one .Net only if dotnet team think .net as a “languge”. a language have a few part :

1. the language
2. Sdk tool chain
3. third party libraries and other thing need to be consider.
4. CPU type
5. OS platform
6. OS version a language to support a platform not care it's version, it just the matter of OS API

The solution to goto One .Net

1. separate the "Core" (eg. Clr + BCL) and the App model dependency, have a basic set of api that means .Net it self .
2. (Current already exists) base on OS platform, each platform will have a "property" called "Platform"
3. base on the App Model location , for that the App model that not open to everyone (like unity3d), add a property called "Feature"

The result:

for unityLibrary myLibA : Feature = unity3d TargetFramework= .net5 myLibB: TargetFramework = .net5 Platform = ios myLibC: TargetFramework = .net5
myapp： TargetFramework = .net5 Platform = win7

and myLibB.

myapp reference  myLibA :   Waring , you do not have Feature: unity3d,   and possiable  `WarningAsError`
myapp reference myLibB:  Warning,  the platform is for `ios`,  and possiable  `WarningAsError`
myapp reference myLibC:   OK

after reference all three lib and configure to remove `WarningAsError` and only call a few class that cross platform in myLibA and mylibB ,  myapp build success and run success.

and for asp.net core wpf winform, if we do not want they be just library, we can add them as Feature too, but with a tool feature install too, those framwork will not install and will include in app, so I hope we can make the .net support static link library , and link them to our app or/and link them to one assembly.

// tool
dotnet feature install aspnetcore
dotnet feature install wpf

// static lib

<ItemGroup  Link="MyDependency.dll"> 
    <PackageReference ... />
    <PackageReference ... />
</ItemGroup>

[Happypig375]

You have your concepts entirely wrong.

the .net5-ios14 .net5-ios15 or android level well once again make several subset of .net 5 , and that is not the One .Net.

No. First of all, net5-ios14 does not have a dot in the front. Second of all, it is a superset of net5 because it provides iOS APIs in addition to .NET cross-platform APIs.

from years ago, that .net core 3.x was in develop, and microsoft make a decision to bring asp.net core (a framework, a app dependency) into the BCL, I wasn't happy because I can bring asp.net core 2 to xamarin.andorid , but I can not bring asp.net core 3.x to Xamarin.

ASP.NET is a server-side technology. Windows, Linux, and macOS can be server hosts, but you never see iOS and Android running as server hosts.

And from that time, Microsoft start it's journey to bring everything that developed by microsoft into BCL.

ASP.NET is NOT in the BCL because you do not see ASP.NET being a preinstalled requirement on every .NET app.

I think the BCL/Clr should only have code to run and build .net apps, it should be small size and stable.

This has always been the case.

Ask: Will each of them have Target Framework Name ? .net5-Tizen1 ,.net5-Tizen2 , .net5-avalonia The answer is : No, so what make .net5-ios and .net5-android so special ? Does the answer be that they the developed by DotNet Team ?

Name	Is an Operating System?
Asp.net Core	No
WPF	No
WinForm	No
Android	Yes
IOS	Yes
UWP	No
Mono	No
Tizen (develped by SamSung, Supported by Xamarin)	Yes
Unity	No
Stride ((formerly Xenko)	No
MonoGame	No
GoDot	No
Wave Engine	No
CRYENGINE	No
Avalonia	No

Therefore, iOS, Android, and Tizen, being Operating Systems, receive their TFMs.

separate the "Core" (eg. Clr + BCL) and the App model dependency, have a basic set of api that means .Net it self . (Current already exists) base on OS platform, each platform will have a "property" called "Platform" base on the App Model location , for that the App model that not open to everyone (like unity3d), add a property called "Feature"

This is already the case.

<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net5.0-windows</TargetFramework> <!--.NET version and OS versrion-->
    <UseWindowsForms>true</UseWindowsForms> <!--App Model-->
  </PropertyGroup>
</Project>

[John0King]

@Happypig375

No. First of all, net5-ios14 does not have a dot in the front. Second of all, it is a superset of net5 because it provides iOS APIs in addition to .NET cross-platform APIs.

sorry that I use the wrong words. but consider this :
if you build a P/invoke library that target windows, you do not need a superset of .net5 , and if the native library exists in IOS or Android or Linux, it is cross platform. and for the IOS/Linux TFM is almost the same, they just add some managed API but not work on other OS. The "superset" exists just do one thing : avoid error reference. and imagining your p/invoke lib has 98% of managed code that work cross-platform and and only a few method not. the superset TFM became a blocker to use the cross-platform, and then your choice only have to cross target, and generate two assembly

and I wonder that Does the TFM like thing exists in Golang , Rust , C/C++, Java ? IMO the TFM try to avoid call to non-exists or not cross-platform method/class being call, but does the IDE/compiler shows such error important than it run ? what kind of developer do not know andorid library does not work on IOS ?

ASP.NET is a server-side technology. Windows, Linux, and macOS can be server hosts, but you never see iOS and Android running as server hosts.

actully I saw before ! if your build an app that send file in same wifi, one solution is to build a http server , and provide web ui , the computer can enter the IP address and using the html/js tech to upload file, or download file. you can option to use asp.net core 2, but not asp.net core 3.x

Therefore, iOS, Android, and Tizen, being Operating Systems, receive their TFMs.

you trying to say, TFM is create for OS . but that is not truth, the TFM exists because the piece of superset code do not want to be a library. for example. today xamarin.form is a liabrary, and if the author do not want the xamarin.forms.dll being include as nuget package, then theoretically their will be a xamarin-forms TFM and xamarin.Anroid and Xamarin.IOS be two superset of xamarin-forms

and I can agree that .net5-android .net5-ios .net5-windows TFM exists for now because nuget,IDE and tons of tool not ready to do condition base on other property, but the TFM like .net5-ios13 .net5-ios14 really necessary ？

in the future, I hope .net5 .net6 TFM is only means that to build this project you need to install the .net5 sdk, instead of some api you want to use that lives in a superset of the .net

[galvesribeiro]

@John0King

Besides your total lack of understand on how it will work, which was greatly clarified by @Happypig375, I would suggest you to watch out for your wording here.

Nobody is lying here and we all would appreciate a fair and respectful conversation with the community.

If you want to understand how it will work, I would suggest you to close this (embarrassing) issue and open one with questions that you want to ask and I'm pretty sure the community will answer with pleasure.

[Happypig375]

if you build a P/invoke library that target windows, you do not need a superset of .net

If it P/Invokes to use Windows APIs, then obviously it won't work for Linux/macOS, right? Specifying net5.0-windows makes this clear.

and if the native library exists in IOS or Android or Linux, it is cross platform.

Even when the native library is cross-platform, the file to P/Inoke is still different. Case study: https://github.com/mono/SkiaSharp/blob/master/binding/Binding/SkiaApi.cs You still need to generate different assemblies for different platforms. To be able to use this in a cross-platform way, you still need to multi-target different platforms each loading a different assembly, and only on top of that you may add a placeholder assembly targeting net5.0.

The "superset" exists just do one thing : avoid error reference.

No. It specifies additional APIs from the Operating System and makes which platforms are supported clear.

imagining your p/invoke lib has 98% of managed code that work cross-platform and and only a few method not. the superset TFM became a blocker to use the cross-platform, and then your choice only have to cross target, and generate two assembly

If you aim for bad design, you can also falsely state that you are cross-platform and throw PlatformNotSupportedException conditionally when P/Invoking. .NET can provide good infrastructure for platform targeting but it can't stop you from designing your libraries badly.

and I wonder that Does the TFM like thing exists in Golang , Rust , C/C++, Java ?

Getting first-class support for using native Operating System functionality is what makes .NET special.

IMO the TFM try to avoid call to non-exists or not cross-platform method/class being call, but does the IDE/compiler shows such error important than it run ?

Because the compiler should guarantee type checks and not behave like JavaScript or Python which only throw errors at runtime?

what kind of developer do not know andorid library does not work on IOS ?

We have nullable annotations so we don't have to check the documentation for every API to see whether null is acceptable. Same here: We don't have to check every library for cross-platform support when TFMs and NuGet can do this for us.

actully I saw before ! if your build an app that send file in same wifi, one solution is to build a http server , and provide web ui , the computer can enter the IP address and using the html/js tech to upload file, or download file. you can option to use asp.net core 2, but not asp.net core 3.x

net5.0-ios and net5.0-android will be able to use netcoreapp3.1 no problem.

you trying to say, TFM is create for OS . but that is not truth, the TFM exists because the piece of superset code do not want to be a library. for example. today xamarin.form is a liabrary, and if the author do not want the xamarin.forms.dll being include as nuget package, then theoretically their will be a xamarin-forms TFM and xamarin.Anroid and Xamarin.IOS be two superset of xamarin-forms

Libraries depend on Operating Systems, not the other way around.

and I can agree that .net5-android .net5-ios .net5-windows TFM exists for now because nuget,IDE and tons of tool not ready to do condition base on other property, but the TFM like .net5-ios13 .net5-ios14 really necessary ？

iOS 14 has additional APIs that iOS 13 doesn't have.

in the future, I hope .net5 .net6 TFM is only means that to build this project you need to install the .net5 sdk, instead of some api you want to use that lives in a superset of the .net

net5.0 is the cross-platform TFM that runs everywhere.

[John0King]

@Happypig375

Even when the native library is cross-platform, the file to P/Inoke is still different.

base on what I know , there no .netcoreapp3.1-windows .netcoreapp3.1-linux TFM, and today P/Invoke is cross platform, and for your example , it can use C# if instead of #if , and [DllImport("libName")] support different file extension name by default, for the case that can not use the default extension name mapping, we can still write different extern class, and test Environment.OSVersion.Platform to call different extern class. multi-target only make assembly smaller.

Getting first-class support for using native Operating System functionality is what makes .NET special.

Sorry that I don't get it. Can you answer my question, Does Java,Golang,Rust,C/C++ have something like TFM for different OS ? Those are static language just like C#.

iOS 14 has additional APIs that iOS 13 doesn't have.

Windows 10 have more api than win7, and windows 10 v2004 have more api than windows 10 1024 for example ToastNotification, that doesn't stop people to use support both win7 and win10 in same app.

and especially have a look of javascript, IE 9 do not have Promise that doesn't stop people using Promise with IE9, In .Net is different than JavaScript .

and maybe I'm not total understand the superset rule . but does a app target .net5-ios14 that can still run on IOS11 (my friend have old Iphone 5 , and he do not want to upgrade, and all app he use still receive updates , ps: last year), if it can't , does that means if you use new api for new OS and it can not support old device with old OS ？ if it can , what will happen when the app access the api it do not exists in IOS11 ? by using if ?

and in the end, I apologize if I use some word make you feel disrespect, I don't meaning it. I'm just think, without addition TFM, .net can do more thing much easier, especially for cross platform libraries. developer do not have to make tough choices between new feature and less customer can use.

[terrajobst]

@John0King

I'm confused by what you're asking. Let me try explain our rationale for the new TFMs.

Moving forward, we can assume the .NET platform APIs to be the same across all environments that .NET runs on. But this doesn’t include .NET bindings for OS APIs, such as:

• WinRT
• iOS bindings
• Android bindings

We could make all APIs available everywhere by throwing. But that would cause significant bloat for any library that bridges OS differences (because those libraries will now transitively depends on all OS bindings it supports).

So we need multi-targeting, meaning compiling for multiple frameworks via <TargetFrameworks>.

.NET has always been about letting developers leverage underlying OS functionality with ease (compare P/Invoke with JNI, for example). Developers should be able to write code like this:

public static class GpsLocation
{
    public static (double Latitude, double Longitude) GetCoordinates()
    {
#if IOS
        return AppleAPI();
#elif Android
        return AndroidAPI();
#elif WINDOWS_UWP
        return UwpAPI();
#else
        throw new PlatformNotSupportedException();
#endif
    }
}

and

public class SkiaSharpImage
{
#if IOS
    public SkiaSharpImage(NSImage nativeImage) { … }
#endif
#if Android
    public SkiaSharpImage(Android.Media.Image nativeImage) { …  }  
#endif
#if UWP
    public SkiaSharpImage(Windows.Media.BitmapImage nativeImage) { … }
#endif
}

The way these different "slices" are expressed in tooling, especially NuGet, is via TFMs. We need a way to say "this binary is for .NET 5 with the Windows OS bindings" and "this binary is for .NET 5 with the iOS bindings". As @Happypig375 explained, the problem is really about OS bindings, not arbitrary libraries (because those can be expressed via regular dependencies).

It seems you're basically asking "why do neither ASP.NET, nor WinForms, WPF, or UWP get their own TFM?"

The answer is that these are app models, not operating systems. And we need to be able to build apps that combine app models, such as a WPF app that hosts a UWP browser control as well as ASP.NET Core web API. TFMs can't be composed this way unless we invent crazy complicated compatibility rules. And we don’t want this complexity. We kind of tried this with Portable Class Libraries (PCLs) and it's extremely hard to explain to developers, doesn't scale very well, and is potentially fragile over time as new TFMs are being added.

So instead of that, we only allow sharing across different TFMs via the net5.0 base TFM. This creates an easy to understand and well defined situation: code is either cross-platform (meaning it will generally run on any OS, or at least multiple OS) and code that only applies to a particular OS.

At this point, it's too late to change the TFM model for .NET 5. We have discussed this feature in the public for a long time, reacted to feedback (such as allowing OS versioning in the TFM) and now we're done for this release, hence I'm closing this issue.

[John0King]

@terrajobst Thans for you explain, and you and your team are doing great job indeed. but I still hope you can get the point that I'm arguing above.

I'm confused by what you're asking

Current (for .net5) I'm vote down the superset TFM of .net5-ios like .net5-ios13 , .net5-ios14 ( not .net5-ios itself, and also include Android, android TFM name is not mentioned in that doc) .

and I still do not know will .net5-ios14 can run on IOS13,IOS12 or not. if it can't ,then to use .net5-ios14 is a big No to me (is that is the fact also for swift and Object-C ?). and if it can , we need C# if to test the api available (base on OS version or other). and then .net5-ios13 is unreasonable to me .

We could make all APIs available everywhere by throwing. But ...

No, I don't want PlatformNotSupportException api. I hope （in the future）those don't exists by default, and can only be install later (by using a tool like dotnet feature install .net-ios dotnet feature install aspnetcore dotnet feature install wpf)
and IDE/Compiler take analysis on a property of .csproj (for example <Features>.net-ios;aspnetcore</Features> ). we can install a nuget that have additional feature to be install and use in our project that do not have those feature, that will show warning instead of error, and maybe use <WarningAsError> to show as error. with this we got one smaller .net BCL (and stable) and move forward for features that we do not need to wait .net Sdk/Runtime to be publish.

for example : asp.net core can try new api, make new change quicker than the Sdk/Runtime/Lanauge . and Features must target a TFM too. for example . aspnetcore feature version 6.x target .net6 , so you can not install this feature to a .net5 TFM project. and a drop back is that asp.net core have many assemblies, and to solve that problem , maybe can introduce static link to .net, the aspnetcore feature will compile to only 1 assembly. for docker, we can pre-install the aspnetcore feature in base image, and with dotnet publish --no-feature-bundle aspnetcore , and for Ios and android we also need to pack with.

[terrajobst]

and I still do not know will .net5-ios14 can run on IOS13,IOS12 or not.

Yes, you will be able to. This scenario is explicitly called out here.

but I still hope you can get the point that I'm arguing above.

I'm not sure I do. It seems to me, your idea of feature shares the same problem as the app model that I explained above (it's the problem of compositionality). The rules for how NuGet would decided which binaries would be hard, if not impossible to make well-defined.