.NET Platform standard remaining work items

[davidfowl]

• NuGet needs to add support for netstandard TFM - Support new TFMs for the .NET Platform Standard NuGet/Home#1691
• NuGet needs to map portable profiles - Map .NET Portable profiles to .NET Standard TFM NuGet/Home#1692
• Flesh out design for TFM file - https://github.com/dotnet/corefx/pull/4344/files
• Update .NET packages to use new TFM

/cc @ericstj @lodejard @anurse @Petermarcu @richlander

[ejsmith]

netstandard seems kind of weird and verbose. What about just using pcl1.0 - pcl1.5? Seems like it's a little more intuitive since people are already familiar with what PCL is and drives home that this is an extension of that.

[davidfowl]

The reason we want to avoid PCL is because in a few years, this will just be a normal library. It's considered a PCL now because we have to retrofit existing platforms. We don't want the name to have that burden forever.

Plus standard matches the "platform standard". We tried netstd but ya know std isn't a great acronym 😄

[ejsmith]

Haha! I see what you are saying and I realize that is where you guys are trying to get. It seems like dotnet was a better name for the long term, but I guess people got really confused over that because of the similarity between net and dotnet. I think maybe the biggest issue with all the negative feedback that you guys are getting is the fact that you exposed a matrix of all the platforms and I don't think people realized just how bad it was before they saw that matrix. I would think about trying to simplify the message and just covering the big platforms and hide the full details away in some sort of spec type document.

[ghost]

std would overweigh the other meaning, if that be a TLD for all programming languages and frameworks standard. Then http://net.std would be super rad! And so would http://cpp.std, http://c.std, http://rust.std, http://go.std, http://csharp.std etc. 😄

[clairernovotny]

For posterity, this is the kind of hoops we had to jump through with dotnet prior to fixing it with the netstandard:
https://github.com/onovotny/BouncyCastle-PCL/blob/a71468c46b50d51bc6b8164fc376cb8321fb83ad/Portable.BouncyCastle.nuspec

The library has a Profile328, Profile259 and "modern" versions with increasing capability. Lots of blank dependency groups and redundant copies in lib dirs. were required to get the correct one to be used by the right platform.

netstandard will fix this and reduce the \lib dir entries down to three again.

[cdrnet]

In what netstandard version would System.Numerics be available (the one with BigInterger and Complex, which is missing in most PCL profiles)? 1.1 and higher?

[davidfowl]

Looks like that's missing from the list. I'm going to get that hooked up to the build so we can see an accurate list thats always up to date.

[davidfowl]

I actually don't see that contract anywhere /cc @ericstj

[davidfowl]

Found it! System.Runtime.Numerics and it goes back to 5.1

[cdrnet]

Ah thanks, didn't realize the contract would have a different name than the assembly (in net, where it was available since at least net40).

[Petermarcu]

Yeah, we refactored things a bunch in .NET Core to make things more componentized and pluggable. There is still plenty of room for us to find ways to make types more easily discoverable.

[ericstj]

We've tried to put most entry-point APIs in the package description. A nuget.org search for the type name usually results in the right result: https://www.nuget.org/packages?q=System.Numerics.BigInteger

[bitbonk]

The document should explain under the section "Terms" what "TFM" stands for. It is mentioned all over the place. I looked it up, but the explanation there might not be so easy to understand for everyone.

[Maxwe11]

@bitbonk TFM means Target framework moniker.

[ghost]

👍 for having a glossary in corefx docs, as available in coreclr docs.

[tmds]

The table at the bottom of https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md shows "CoreFx APIs" vs ".NET Platform Standard version". Currenty arrows and Xes are used to show the available API in a platform standard. Probably the CoreFX APIs need to grow over time? So is it the intention to fill this table with CoreFX API version numbers? E.g. netstandard1.3 and netstandard1.4 could have Some.Contract 1.0 API and netstandard1.5 can have an extended Some.Contract API 1.1.

[davidfowl]

Yes this needs to be deleted and we should generate new data every build.

[ericstj]

I'm generating that file with dotnet/corefx#7327 closing out this issue for now since the work it was tracking is done.

[aidapsibr]

Is netstandard ready to target in VS 2015 u2? The doc says to check here for status, but lists TBD.