Add TFM for .NET nanoFramework

[terrajobst]

TFM Component	Value
Friendly name	netnano
TFI	.NETnanoFramework

Goals

• NuGet needs to able to recognize the TFM for .NET nanoFramework and select assets from a NuGet package into a project that targets .NET nanoFramework.
• NuGet needs to allow creating a NuGet package that includes assets for .NET nanoFramework.
• Normal versioning rules need to apply (e.g. a package can offer assets for multiple versions of the .NET nanoFramework and NuGet will use the largest version that is less or equal to the targeted version).
• Once NuGet knows of the TFM for .NET nanoFramework, the .NET nanoFramework maintainers should be able to ship new versions without having to submit any changes to the NuGet client.

Non-Goals

• NuGet doesn't need to understand any compatibility relationships between .NET nanoFramework and other TFM.

The spec is here

[josesimoes]

Hey! Anything I can help with to make this happen? 😃

[terrajobst]

@josesimoes the spec'ed work doesn't include any work in the SDK yet; I honestly don't even know whether just adding the TFM to NuGet is sufficient in unblocking you from getting onto the SDK-style projects. One thing that would help is if you could start prototyping an SDK-based build approach and tell us what you'd need to support building for .NET nanoFramework using the .NET SDK.

[josesimoes]

@josesimoes the spec'ed work doesn't include any work in the SDK yet; I honestly don't even know whether just adding the TFM to NuGet is sufficient in unblocking you from getting onto the SDK-style projects. One thing that would help is if you could start prototyping an SDK-based build approach and tell us what you'd need to support building for .NET nanoFramework using the .NET SDK.

Understood. I'll start working on that and report back.

[josesimoes]

Hey!

Working on the SDK for nanoFramework and it's looking good.
I'm now stuck because of 2 blockers:

1. VS is not able to perform the package restore because the task doesn't recognize the TFM.
2. I'm not able to pack because the task doesn't know the TFM either.

Any chance this issue can get some ❤️ and make this happen? 😄
I'll be happy to assist just like I did with the CLI in NuGet/NuGet.Client#3943 just need some pointers and general guidance.

With these working I believe we would be very close to have an SDK for nanoFramework.

[zkat]

cc @aortiz-msft looks like this is getting some traction!

[josesimoes]

Heads up on this: I've managed to build mscorlib for .NET nanoFramework with the WIP SDK being as a csproj!
This is somewhat promising because with this the amount of changes required in NuGet and .NET targets & props are significantly decreased.

Still unknown on what concerns the debugging launching from VS (which was one of the drivers for using nfproj) can only test after being able to pack and restore. 😉 Happy to further discuss this, if helpful at this point.

[zivkan]

@josesimoes NuGet needs at least two "names"/identifiers for a supported TFM, a TargetFrameworkIdentifier (used as part of the TargetFrameworkMoniker in MSBuild's common props), and a "short folder name" which is used both in nupkg lib/<name>/ paths, and also the name specified in SDK style projects <TargetFrameworks> elements.

Do you have any preferences? My suggestion for both would be nanoFramework, so <TargetFraamework>nanoFramework1.0<TargetFramework> gets converted into TargetFrameworkMoniker = nanoFramework,Version=1.0, and nupkgs will contain lib/nanoFramework1.0/my.dll.

Does that sound ok with you, or would you like different identifiers?

[josesimoes]

@zivkan nothing against that. Please go with those! 👍

[zivkan]

I just realized the very first comment in the issue proposed different values 🤦‍♂️

I'll go with Immo's proposed netnano and .NETnanoFramework unless someone objects.

[terrajobst]

No objections either way; we could use the values you proposed, assuming @josesimoes is OK with that which sounds like he is :-)

[josesimoes]

@zivkan good point! This was a while ago and I forgot the proposed values. 🤪
Actually there is some work already done on the future SDK that is already using those. So please let's go with the original proposal.