Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.NET Platform standard remaining work items #4367

Closed
davidfowl opened this Issue Nov 6, 2015 · 19 comments

Comments

Projects
None yet
@davidfowl
Copy link
Contributor

commented Nov 6, 2015

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

@davidfowl davidfowl added the packaging label Nov 6, 2015

@ejsmith

This comment has been minimized.

Copy link

commented Nov 6, 2015

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

This comment has been minimized.

Copy link
Contributor Author

commented Nov 6, 2015

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

This comment has been minimized.

Copy link

commented Nov 6, 2015

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.

@joshfree joshfree added this to the 1.0.0-rc2 milestone Nov 6, 2015

@ghost

This comment has been minimized.

Copy link

commented Nov 6, 2015

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. 😄

@onovotny

This comment has been minimized.

Copy link
Member

commented Nov 9, 2015

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

This comment has been minimized.

Copy link

commented Nov 9, 2015

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

This comment has been minimized.

Copy link
Contributor Author

commented Nov 9, 2015

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

This comment has been minimized.

Copy link
Contributor Author

commented Nov 9, 2015

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

@davidfowl

This comment has been minimized.

Copy link
Contributor Author

commented Nov 9, 2015

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

@khellang khellang referenced this issue Nov 9, 2015

Closed

.NET Core #535

@cdrnet

This comment has been minimized.

Copy link

commented Nov 10, 2015

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

This comment has been minimized.

Copy link
Member

commented Nov 10, 2015

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.

@khellang khellang referenced this issue Nov 10, 2015

Closed

[EXPERIMENT] DNX Support #960

0 of 5 tasks complete
@ericstj

This comment has been minimized.

Copy link
Member

commented Nov 10, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Jan 27, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Jan 27, 2016

@bitbonk TFM means Target framework moniker.

davidfowl added a commit that referenced this issue Jan 27, 2016

@ghost

This comment has been minimized.

Copy link

commented Jan 27, 2016

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

@tmds

This comment has been minimized.

Copy link
Member

commented Mar 23, 2016

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

This comment has been minimized.

Copy link
Contributor Author

commented Mar 23, 2016

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

@ericstj

This comment has been minimized.

Copy link
Member

commented Mar 29, 2016

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

@psibernetic

This comment has been minimized.

Copy link

commented May 3, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.