TFM for .NET nanoFramework

[josesimoes]

Would like to request a TFM for .NET nanoFramework.
This would be much helpful to properly handle all the places where TFMs are used: for the project system to the NuGet packages.
Considering that we are the natural successor of the defunct .NET Micro Framework, and that we are part of the .NET Foundation for sometime now (therefore part of the .NET ecosystem) this makes sense.
There is a precedent for this with .NETMF that had it's own and, to the best of my knowledge, is still around.
#174 was just merged, so it may not be too late to consider this. 😉

[MichalStrehovsky]

cc @terrajobst

I assume this is a request similar to NuGet/Home#9347? A subset of the existing TFM that should be considered compatible with the mainstream TFMs?

[terrajobst]

Assuming it's similar to the Unity request, what compatibility do you have in mind for existing TFMs? Considering that Micro Framework didn't support generics, I assume the upper boundary would be a one way compatibility with the "big" .NET.

I'm hesitant to add support for this though, because it means that we have to figure out how we can maintain the subset relationship between Nano Framework and the others. Given that you wouldn't be able to implement .NET Standard nor be based on .NET 5 we'd have to maintain it as version mapping (e.g. Nana Framework 1.0 is compatible with .NET 5, 1.1 is compatible with .NET 6 and so on). But those are costly and non trivial to coordinate.

If you can live without any compatibility relationship (except, of course with previous versions of Nana Framework itself) it should be relatively straightforward.

Other question is: what kind of support are you looking for? When we say "adding support for a TFM" it usually means compatibility rules in NuGet. But there are other parts that are needed for an end-to-end scenario, for example, how would people acquire Nana Framework? How do they reference it from their project files? The latter is often referred to as a targeting pack.

It might be best if we could hop on a video call and have a 30-60 minute discussion. Please send me an email to immol at microsoft dot com and we can set it up.

[josesimoes]

Assuming it's similar to the Unity request, what compatibility do you have in mind for existing TFMs? Considering that Micro Framework didn't support generics, I assume the upper boundary would be a one way compatibility with the "big" .NET.

Good news here: generics are in the works! We have it working in the type system and execution engine. Currently working on adding the required support in the degugger engine.

I'm hesitant to add support for this though, because it means that we have to figure out how we can maintain the subset relationship between Nano Framework and the others. Given that you wouldn't be able to implement .NET Standard nor be based on .NET 5 we'd have to maintain it as version mapping (e.g. Nana Framework 1.0 is compatible with .NET 5, 1.1 is compatible with .NET 6 and so on). But those are costly and non trivial to coordinate.

If you can live without any compatibility relationship (except, of course with previous versions of Nana Framework itself) it should be relatively straightforward.

Agreed here! Because of the constraints of the platforms we run in, we only implement a subset of the API and we won't ever achieve full compatibility. But that's the point of it, so nothing new here. Because of this, I think it's quite all right, actually desirable and on purpose, to live without that compatibility relationship.

Other question is: what kind of support are you looking for? When we say "adding support for a TFM" it usually means compatibility rules in NuGet. But there are other parts that are needed for an end-to-end scenario, for example, how would people acquire Nana Framework? How do they reference it from their project files? The latter is often referred to as a targeting pack.

NuGet and project system are the main concerns. As it is now, we are kind of pushing it and stretching nuget and the project system.
We have "nfproj" instead of "csproj" and all the libraries (mscorlib included) are distributed through NuGet packages.

It might be best if we could hop on a video call and have a 30-60 minute discussion. Please send me an email to immol at microsoft dot com and we can set it up.

Sure! Thanks.

[hansmbakker]

Is there any followup to this, besides this document?

[josesimoes]

@hansmbakker yes there is.
Besides the TFM becoming real, nuget CLI "knows" the TFM and it can restore and update nfproj files. This was a mandatory step towards moving to SDK projects (which is moving with a very slow pace due to lack of time).

[hansmbakker]

Great to hear, thank you for sharing!