using System; | |
namespace Analogy | |
{ | |
// Each interface represents a target framework and methods represents groups of APIs available on that target framework. | |
// The goal is to show the relationship between .NET Standard API surface and other .NET platforms | |
// .NET Standard | |
interface INetStandard10 | |
{ | |
void Primitives(); | |
void Reflection(); | |
void Tasks(); | |
void Collections(); | |
void Linq(); | |
} | |
interface INetStandard11 : INetStandard10 | |
{ | |
void ConcurrentCollections(); | |
void InteropServices(); | |
} | |
interface INetStandard12 : INetStandard11 | |
{ | |
void ThreadingTimer(); | |
} | |
interface INetStandard13 : INetStandard12 | |
{ | |
void FileSystem(); | |
void Console(); | |
void ThreadPool(); | |
void Process(); | |
void Sockets(); | |
void AsyncLocal(); | |
} | |
interface INetStandard14 : INetStandard13 | |
{ | |
void IsolatedStorage(); | |
} | |
interface INetStandard15 : INetStandard14 | |
{ | |
void AssemblyLoadContext(); | |
} | |
// .NET Framework | |
interface INetFramework45 : INetStandard11 | |
{ | |
void FileSystem(); | |
void Console(); | |
void ThreadPool(); | |
void Crypto(); | |
void WebSockets(); | |
void Process(); | |
void Sockets(); | |
void AppDomain(); | |
void Xml(); | |
void Drawing(); | |
void SystemWeb(); | |
void WPF(); | |
void WindowsForms(); | |
void WCF(); | |
} | |
interface INetFramework451 : INetFramework45, INetStandard12 | |
{ | |
// TODO: .NET Framework 4.5.1 specific APIs | |
} | |
interface INetFramework452 : INetFramework451, INetStandard12 | |
{ | |
// TODO: .NET Framework 4.5.2 specific APIs | |
} | |
interface INetFramework46 : INetFramework452, INetStandard13 | |
{ | |
// TODO: .NET Framework 4.6 specific APIs | |
} | |
interface INetFramework461 : INetFramework46, INetStandard14 | |
{ | |
// TODO: .NET Framework 4.6.1 specific APIs | |
} | |
interface INetFramework462 : INetFramework461, INetStandard15 | |
{ | |
// TODO: .NET Framework 4.6 specific APIs | |
} | |
// Mono | |
interface IMono43 : INetFramework46 | |
{ | |
void MonoSpecificApi(); | |
} | |
// Windows Universal Platform | |
interface IWindowsUniversalPlatform : INetStandard14 | |
{ | |
void GPS(); | |
void Xaml(); | |
} | |
// Xamarin | |
interface IXamarinIOS : INetStandard15 | |
{ | |
void AppleAPIs(); | |
} | |
interface IXamarinAndroid : INetStandard15 | |
{ | |
void GoogleAPIs(); | |
} | |
// .NET Core | |
interface INetCoreApp10 : INetStandard15 | |
{ | |
} | |
// Future platform | |
interface ISomeFuturePlatform : INetStandard13 | |
{ | |
// A future platform chooses to implement a specific .NET Standard version. | |
// All libraries that target that version are instantly compatible with this new | |
// platform | |
} | |
} |
namespace Analogy | |
{ | |
/// <summary> | |
/// This example shows that a library that needs access to target .NET Standard 1.3 | |
/// can only access APIs available in that .NET Standard. Even though similar the APIs exist on .NET | |
/// Framework 4.5, it implements a version of .NET Standard that isn't compatible with the library. | |
/// </summary>INetCoreApp10 | |
class Example1 | |
{ | |
public void Net45Application(INetFramework45 platform) | |
{ | |
// .NET Framework 4.5 has access to all .NET Framework APIs | |
platform.FileSystem(); | |
platform.Console(); | |
// This fails because .NET Framework 4.5 does not implement .NET Standard 1.3 | |
// Argument 1: cannot convert from 'Analogy.INetFramework45' to 'Analogy.INetStandard13' | |
NetStandardLibrary13(platform); | |
} | |
public void NetStandardLibrary13(INetStandard13 platform) | |
{ | |
platform.FileSystem(); | |
platform.Console(); | |
} | |
} | |
/// <summary> | |
/// This example shows a library targeting multiple frameworks and 2 different applications | |
/// using that library. MultipleTargetsLibrary needs access to the FileSystem, that API was only available | |
/// in .NET Standard 1.3. .NET Standard 1.3 only works with .NET Framework 4.6. Because of this | |
/// MultipleTargetsLibrary needs to add support for .NET Framework 4.5 explicitly. | |
/// </summary> | |
class Example2 | |
{ | |
public void Net45Application(INetFramework451 platform) | |
{ | |
// On the .NET 4.5.1 application, the INetFramework45 implementation is choson | |
MultipleTargetsLibrary(platform); | |
} | |
public void NetCoreApplication(INetCoreApp10 platform) | |
{ | |
// On the .NET Core 1.0 application, the INetStandard13 implementation is choson | |
MultipleTargetsLibrary(platform); | |
} | |
public void MultipleTargetsLibrary(INetFramework45 platform) | |
{ | |
platform.FileSystem(); | |
} | |
public void MultipleTargetsLibrary(INetStandard13 platform) | |
{ | |
platform.FileSystem(); | |
} | |
} | |
/// <summary> | |
/// This example shows how future platforms can be added without the need to change libraries that | |
/// target the .NET Standard. JSON.NET targets .NET Standard 1.0 and can run on *ANY* platform that implements | |
/// the standard. | |
/// </summary> | |
class Example3 | |
{ | |
/// <summary> | |
/// This future platform implements .NET Standard 1.3 | |
/// </summary> | |
public void FuturePlatformApplication(ISomeFuturePlatform platform) | |
{ | |
// You are able to use JSON.NET with the future platform without recompiling JSON.NET | |
JsonNet(platform); | |
} | |
/// <summary> | |
/// This method represents the implementation of JSON.NET. JSON.NET supports .NET Standard 1.0. | |
/// </summary> | |
public void JsonNet(INetStandard10 platform) | |
{ | |
platform.Linq(); | |
platform.Reflection(); | |
platform.Collections(); | |
} | |
} | |
} |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
bgever
commented
Apr 22, 2016
My initial expectation was that I need to use |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
davidfowl
Apr 22, 2016
@bgever Ifdefs only need to be used in Example2 https://gist.github.com/davidfowl/8939f305567e1755412d6dc0b8baf1b7#file-example1-cs-L38.
@bgever Ifdefs only need to be used in Example2 https://gist.github.com/davidfowl/8939f305567e1755412d6dc0b8baf1b7#file-example1-cs-L38. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
colhountech
commented
Apr 22, 2016
Yup. It clicks. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
bgever
Apr 22, 2016
@davidfowl Thanks, I think the fact that you'd need fewer #if
's is .NET Standard's biggest selling point. As it cures a pain point.
bgever
commented
Apr 22, 2016
•
edited
edited
@davidfowl Thanks, I think the fact that you'd need fewer |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
kdaveid
commented
Apr 22, 2016
Yup. It clicks big time here too. Thanks a lot! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
MichaCo
Apr 22, 2016
In Example 2, I could also target both, NetStandard11 (and NetStandard13) to support NetFramework45, right?
MichaCo
commented
Apr 22, 2016
In Example 2, I could also target both, NetStandard11 (and NetStandard13) to support NetFramework45, right? |
@MichaCo yes but NetStandard11 does not have FileSystem() |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
pebezo
commented
Apr 22, 2016
Do you have the option to remove stuff / deprecate? Or is it always additive? |
@pebezo Up until now it's always been additive. People hate when you remove APIs but it's one of the things we struggle with. Ideally we would never remove APIs, but potentially deprecate them. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
ErikSchierboom
commented
Apr 22, 2016
it makes sense now! Great analogy. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
pauldotknopf
Apr 22, 2016
Developer documentation, for developers. This approach should be used more often!
pauldotknopf
commented
Apr 22, 2016
Developer documentation, for developers. This approach should be used more often! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
SteveSandersonMS
Apr 22, 2016
This is great as a way of illustrating which APIs would be available in which circumstances. A really novel and cool way of expressing that :)
I think it still leaves open the question of "why does the netstandard concept exist?", because a developer can still wonder why it's not sufficient just to have different .NET framework versions and allow newly-invented platforms to pick which .NET framework version they want to implement support for. To motivate the existence of the netstandard concept, it would be useful to spell out what pain point or conflict would occur otherwise. Though maybe that's a different topic than you're addressing with this.
SteveSandersonMS
commented
Apr 22, 2016
This is great as a way of illustrating which APIs would be available in which circumstances. A really novel and cool way of expressing that :) I think it still leaves open the question of "why does the netstandard concept exist?", because a developer can still wonder why it's not sufficient just to have different .NET framework versions and allow newly-invented platforms to pick which .NET framework version they want to implement support for. To motivate the existence of the netstandard concept, it would be useful to spell out what pain point or conflict would occur otherwise. Though maybe that's a different topic than you're addressing with this. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
eadordzhiev
commented
Apr 22, 2016
Awesome, thanks! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
bizl
commented
Apr 22, 2016
it makes sense. whether we like it or not ;) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
kjbetz
commented
Apr 22, 2016
I think this helps put it into more perspective for me. Thank you! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
tugberkugurlu
Apr 22, 2016
@davidfowl So, today there are 1.0, 1.1, 1.2, 1.3, 1.4, 1.5 for .NET Platform Standard. Are these to cover what is out there today? They seem to be mapping to different .NET framework versions.
If not, in what circumstances do you expect to have .NET Platform Standard 1.6?
tugberkugurlu
commented
Apr 22, 2016
@davidfowl So, today there are 1.0, 1.1, 1.2, 1.3, 1.4, 1.5 for .NET Platform Standard. Are these to cover what is out there today? They seem to be mapping to different .NET framework versions. If not, in what circumstances do you expect to have .NET Platform Standard 1.6? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
discostu105
Apr 22, 2016
Cool explanation! So, I can chose in my application to reference the standard (netstandard1.X), or a certain implementation (netframeworkX, netcoreappX, ...), right? Which packages will I actually depend on if I reference either of those?
If I reference netcoreappX, which AssemblyRef's will actually be generated in my compiled dll? How can the compiler know? Or do I have to additionally specify certain package dependencies (e.g. System.Threading.Thread)?
discostu105
commented
Apr 22, 2016
Cool explanation! So, I can chose in my application to reference the standard (netstandard1.X), or a certain implementation (netframeworkX, netcoreappX, ...), right? Which packages will I actually depend on if I reference either of those? If I reference netcoreappX, which AssemblyRef's will actually be generated in my compiled dll? How can the compiler know? Or do I have to additionally specify certain package dependencies (e.g. System.Threading.Thread)? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
stevedesmond-ca
commented
Apr 22, 2016
I think the interface/implements metaphor really helps |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
BenjaminAbt
commented
Apr 22, 2016
Great stuff. This will help! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
davidpurkiss
commented
Apr 22, 2016
Click! Yes, makes a lot of sense. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
davidfowl
Apr 22, 2016
@davidfowl So, today there are 1.0, 1.1, 1.2, 1.3, 1.4, 1.5 for .NET Platform Standard. Are these to cover what is out there today? They seem to be mapping to different .NET framework versions.
We had to back version things so that they were compatible with the .NET Framework.
If not, in what circumstances do you expect to have .NET Platform Standard 1.6?
.NET Core will inevitably outpace .NET Framework with respect to new API surface area. I'd expect that when we add an API that we want to appear on all platforms, or that is something that cannot be implemented on top of what is already in the standard, we'll need to create a new one.
An example might be changes to Array, Stream or one of the primitives types. When we add Slices, it may not be possible to do it in a way that works on .NET Framework from day 1, so we might need a new standard with that capability.
We had to back version things so that they were compatible with the .NET Framework.
.NET Core will inevitably outpace .NET Framework with respect to new API surface area. I'd expect that when we add an API that we want to appear on all platforms, or that is something that cannot be implemented on top of what is already in the standard, we'll need to create a new one. An example might be changes to Array, Stream or one of the primitives types. When we add Slices, it may not be possible to do it in a way that works on .NET Framework from day 1, so we might need a new standard with that capability. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
anurse
Apr 22, 2016
I think it still leaves open the question of "why does the netstandard concept exist?"
This is a good question. It definitely adds a risk of additional fragmentation. It basically comes down to history. The .NET Framework is a Windows component, and despite some of the original ideals, it's basically been designed to run on Windows and Windows only. Thus, the API surface a package expects when it targets net451
or similar, is closely tied to Windows. Other projects have implemented the full .NET Framework surface area cross-platform but it remains a problematic approach (Mono does a great job implementing what they can, but there are warts and edge cases, and it's kinda unavoidable given the way the APIs were designed).
So, with .NET Core, the goal is to produce something that treats portability and cross-platform support as a first-class design goal. As a result, things are missing or have to be implemented in new ways. So rather than try and shoe-horn .NET Core into the .NET Framework spectrum somewhere, we created "The .NET Platform Standard".
Basically, we took the parts of .NET Framework that we knew we could do portably, or have very clearly defined edge cases (for example, Microsoft.Win32.Registry: one would hope it's obvious to developers that it's only going to work on Windows ;)) and put them into a new bucket: netstandard
. We also took the previous approach of Portable Class Libraries and created a new model for managing that going forward (the .NET Standard versions described above). We cut ties with the legacy stuff in order to produce a cleaner, future-looking, solution. Despite "cutting ties" with legacy stuff, we were also able to line the new world up with subsets of the old .NET Framework/Silverlight worlds, producing netstandard1.0
-netstandard1.4
(which basically cover compatible subsets of the existing .NET Framework stuff). Which is why the new stuff starts at netstandard1.5
. We were able to retcon the old .NET Framework/Silverlight stuff into supporting some level of the .NET Platform Standard
With this new model, we have an extremely clear set of rules for Package Authors, App Developers, and Platform Developers. There are still confusing edge cases if you go really close to the edges, but in general, the rules are simple:
Package Authors: Target the lowest netstandard
version you can. You will run on all platforms that support that netstandard
version or higher
App Developers: You target the platform you're writing for (uap10.0
, net451
, xamarinios
, etc.). That platform subscribes to a particular version of the .NET Platform Standard (say 1.5
). You can install any package targeting that version or lower
Platform Developers: Pick the highest netstandard
version you can. This will mean the broadest set of existing packages will work. This means you have to provide implementations for most of the System.
packages on your platform. For the few edge cases where that will be hard (for example, FileSystem APIs on a tiny IoT device or something), you either need to lower your netstandard
target to remove that API, or just throw PlatformNotSupportedException
.
What's really important about that last rule is that creating a new platform means you instantly gain access to all the packages built to target the netstandard
versions you support. In the past, new platforms meant adding checkboxes to the PCL dialog, but now, existing packages just work. This is a huge win for all three groups because it means Package Authors don't have to go through hoops to make sure their packages will work on a bunch of platforms, they just target .NET Standard. App Developers don't have to crawl through NuGet dependencies trying to figure out if the package they want will work, they just look at the .NET Standard version it supports. And Platform Developers don't have to go through hoops adding XML files to VS just to hook up a bunch of portable profiles. The .NET Platform Standard describes all of that in a clear, linear set of APIs.
So yeah, it's a new thing. But it's the last new thing. We promise. For reals this time. Trust us ;)[1]
[1] Yeah, obviously we might still get it wrong, but this is so much better than it was, so we're getting much closer to the nirvana of a perfect system, even if we haven't made it yet :)
anurse
commented
Apr 22, 2016
•
edited
edited
This is a good question. It definitely adds a risk of additional fragmentation. It basically comes down to history. The .NET Framework is a Windows component, and despite some of the original ideals, it's basically been designed to run on Windows and Windows only. Thus, the API surface a package expects when it targets So, with .NET Core, the goal is to produce something that treats portability and cross-platform support as a first-class design goal. As a result, things are missing or have to be implemented in new ways. So rather than try and shoe-horn .NET Core into the .NET Framework spectrum somewhere, we created "The .NET Platform Standard". Basically, we took the parts of .NET Framework that we knew we could do portably, or have very clearly defined edge cases (for example, Microsoft.Win32.Registry: one would hope it's obvious to developers that it's only going to work on Windows ;)) and put them into a new bucket: With this new model, we have an extremely clear set of rules for Package Authors, App Developers, and Platform Developers. There are still confusing edge cases if you go really close to the edges, but in general, the rules are simple: Package Authors: Target the lowest App Developers: You target the platform you're writing for ( Platform Developers: Pick the highest What's really important about that last rule is that creating a new platform means you instantly gain access to all the packages built to target the So yeah, it's a new thing. But it's the last new thing. We promise. For reals this time. Trust us ;)[1] [1] Yeah, obviously we might still get it wrong, but this is so much better than it was, so we're getting much closer to the nirvana of a perfect system, even if we haven't made it yet :) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
awright18
Apr 22, 2016
I like the diagram, the idea makes sense, but I have some questions. And feel free to let me know if I should ask these in another forum.
So is the thought that is a requirement for packages on the new core platform? Or will someone still be able piece together what they want from individual packages? And might that scenario be supported? (not asking for definitive answers).
Is the primary benefit stable cross platform apis that can be versioned/patched independently that still has the "feel" of today's .NET, and are optionally portable (side by side compatible)? Also, if some entity wants to build their own xyzstandard (set of packages) in a similar manner on top of or instead of netstandard if that would be possible as well via this mechanism, or are these netstandards baked into nuget?
awright18
commented
Apr 22, 2016
I like the diagram, the idea makes sense, but I have some questions. And feel free to let me know if I should ask these in another forum. So is the thought that is a requirement for packages on the new core platform? Or will someone still be able piece together what they want from individual packages? And might that scenario be supported? (not asking for definitive answers). Is the primary benefit stable cross platform apis that can be versioned/patched independently that still has the "feel" of today's .NET, and are optionally portable (side by side compatible)? Also, if some entity wants to build their own xyzstandard (set of packages) in a similar manner on top of or instead of netstandard if that would be possible as well via this mechanism, or are these netstandards baked into nuget? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
anurse
Apr 22, 2016
netstandard
is baked in to nuget, just like net45
, wp80
, etc. are. So right now, if you are a platform owner and you want NuGet to work, you need to send a PR to NuGet to define your framework name (xyz
) and map it to netstandard
somehow. However, we have ideas around decentralizing that a little and allowing users to define their own identifiers and map them without having to change NuGet code. That's all just ideas right now, in the short term, if you have a platform you want to add you have to work with the NuGet team to add it, but as we iterate on this, I think it'll be a lot easier to create new .NET-based platforms.
anurse
commented
Apr 22, 2016
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
damageboy
commented
Apr 23, 2016
Very useful. Thanks! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
anurse
Apr 23, 2016
Or will someone still be able piece together what they want from individual packages?
Within the .NET Platform Standard, we still have the individual packages. In the end, Platform Authors still have the ability to piece together their own set of packages and make it work. However, the Standard creates a base on which Library Authors can develop, so Platform Authors are strongly encouraged to adopt a version of the Standard.
We call it a "Platform Standard" because it is a Standard, much like HTTP or TCP. You can take a few pieces of HTTP and implement them on your Server (Platform) and Clients (Libraries) that support your special version of the Protocol (Standard) will work. However, if you fully implement HTTP, then ANY HTTP Client (Library targeting the Platform Standard) can work with your Server (Platform). The great thing about .NET Core is that it's fully open-source and detached from Windows so you can do what you want with it. The .NET Platform Standard is about adding a layer of structure on top of that flexibility to make all our lives simpler :)
anurse
commented
Apr 23, 2016
•
edited
edited
Within the .NET Platform Standard, we still have the individual packages. In the end, Platform Authors still have the ability to piece together their own set of packages and make it work. However, the Standard creates a base on which Library Authors can develop, so Platform Authors are strongly encouraged to adopt a version of the Standard. We call it a "Platform Standard" because it is a Standard, much like HTTP or TCP. You can take a few pieces of HTTP and implement them on your Server (Platform) and Clients (Libraries) that support your special version of the Protocol (Standard) will work. However, if you fully implement HTTP, then ANY HTTP Client (Library targeting the Platform Standard) can work with your Server (Platform). The great thing about .NET Core is that it's fully open-source and detached from Windows so you can do what you want with it. The .NET Platform Standard is about adding a layer of structure on top of that flexibility to make all our lives simpler :) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
NenessNC
commented
Apr 23, 2016
Awesome ! Thanks a lot ! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
DavidBurela
Apr 24, 2016
Which is why the new stuff starts at netstandard1.5
I really like @davidfowl idea during one of his presentations, that the older legacy versions start at 0.5 and the first real version starts at 1.0. Instead of 1.0 - 1.5.
DavidBurela
commented
Apr 24, 2016
I really like @davidfowl idea during one of his presentations, that the older legacy versions start at 0.5 and the first real version starts at 1.0. Instead of 1.0 - 1.5. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
Northgates-Systems
Apr 28, 2016
Thanks @davidfowl, explained it clearly and consisely. - I have been battling this for ages.
Moving into future in confidence.
Northgates-Systems
commented
Apr 28, 2016
Thanks @davidfowl, explained it clearly and consisely. - I have been battling this for ages.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
ealsur
Apr 29, 2016
copy paste screenshot to Powerpoint That should do it on any dev oriented presentation this year :)
ealsur
commented
Apr 29, 2016
copy paste screenshot to Powerpoint That should do it on any dev oriented presentation this year :) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
dasMulli
May 8, 2016
@davidfowl Awesome work ;)
But what about netstandard1.6? I think this was added a few days ago and netcoreapp1.0 is now based on that.. NuGet/Home#2536
dasMulli
commented
May 8, 2016
@davidfowl Awesome work ;) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
colin-young
May 11, 2016
While this explanation seems to be very clear and concise, there is one thing I don't understand: I currently have a project that targets .Net Platform 5.4
and has a dependency on System.Security.Cryptography.{Algorithms+Csp+Primitives}
. My understanding is that I should now target netstandard1.3
, but according to my understanding, I only get crypto if I target NetFramework4.5
or higher, and I won't get it with anything that targets core CLR. Is that correct? Something new since dnxcore50 days (when this project was originally created)?
colin-young
commented
May 11, 2016
While this explanation seems to be very clear and concise, there is one thing I don't understand: I currently have a project that targets |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
sandersaares
May 13, 2016
What is the authoritative place that defines what is in what .NET Standard version? Is there a place where I can easily see the differences between two versions? A change history of sorts?
sandersaares
commented
May 13, 2016
•
edited
edited
What is the authoritative place that defines what is in what .NET Standard version? Is there a place where I can easily see the differences between two versions? A change history of sorts? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
deepumi
Jun 3, 2016
Wow, this is Awesome, In this case we would able to target as many platform we want like UWP or MONO or any standard .net platform.
@davidfowl, thank you.
deepumi
commented
Jun 3, 2016
Wow, this is Awesome, In this case we would able to target as many platform we want like UWP or MONO or any standard .net platform. @davidfowl, thank you. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
sgwatgit
Jun 8, 2016
This is great! Despite watching the ASP.NET community standups every week I think this is the first time it has all clicked for me.
Thanks.
sgwatgit
commented
Jun 8, 2016
This is great! Despite watching the ASP.NET community standups every week I think this is the first time it has all clicked for me. Thanks. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
richardgavel
Jun 14, 2016
One thought. Shouldn't stuff like .NET Framework 4.5.2 in this visualization be considered classes, not interfaces? That makes more clear the distinction that .NET standard (or rather a version of it) is purely an "interface" that one or more frameworks implement.
richardgavel
commented
Jun 14, 2016
One thought. Shouldn't stuff like .NET Framework 4.5.2 in this visualization be considered classes, not interfaces? That makes more clear the distinction that .NET standard (or rather a version of it) is purely an "interface" that one or more frameworks implement. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
eanyanwu
Jun 16, 2016
Wow ... this was oddly more helpful than normal sentences.
The
.NETFramework,Version=4.6
framework represents the available APIs in the .NET Framework 4.6. [1]
Huh....?
The
.NETStandard,Version=1.3
framework is a package-based framework. It relies on packages that target the framework to define and expose APIs in terms of the framework.[1]
Wut?
[1] https://dotnet.github.io/docs/core-concepts/packages.html
interface INetStandard10
{
void Primitives();
void Reflection();
void Tasks();
void Collections();
void Linq();
}
AH. GOT IT. THANKS.
eanyanwu
commented
Jun 16, 2016
Wow ... this was oddly more helpful than normal sentences.
Huh....?
Wut? interface INetStandard10
{
void Primitives();
void Reflection();
void Tasks();
void Collections();
void Linq();
} AH. GOT IT. THANKS. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
jcob-ross
commented
Jul 1, 2016
Clicked, thanks! |
mduu
commented
Jul 28, 2016
Clicked a lot! Thx. Additional explanations from @anurse rocked too! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
ArturKarbone
commented
Aug 27, 2016
Clicked. Thanks |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
tthiery
Sep 27, 2016
@davidfowl Can you give us an update. .NET Standard 2.0 needs an awesome explaination ;)
tthiery
commented
Sep 27, 2016
@davidfowl Can you give us an update. .NET Standard 2.0 needs an awesome explaination ;) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
adamralph
Oct 20, 2016
I guess this has moved to https://github.com/davidfowl/NetStandard/blob/master/platforms.cs ?
FWIW I sent a PR to add 2.0 - davidfowl/NetStandard#10
adamralph
commented
Oct 20, 2016
I guess this has moved to https://github.com/davidfowl/NetStandard/blob/master/platforms.cs ? FWIW I sent a PR to add 2.0 - davidfowl/NetStandard#10 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
scottt732
Nov 8, 2016
+1 @adamralph. This is also how I interpreted https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/
scottt732
commented
Nov 8, 2016
+1 @adamralph. This is also how I interpreted https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/ |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
zoltanarvai
commented
Nov 19, 2016
Clicked! I love it! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
valerysntx
Nov 20, 2016
/* IComparable<SemVer>? */
public class INetStandard13: IComparable, IComparable<INetCoreApp10>, IEquatable
{
}
valerysntx
commented
Nov 20, 2016
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
bitbonk
Nov 30, 2016
This could need an update for .NET Standard 1.6 and maybe 2.0, even if it is not fully baked yet.
bitbonk
commented
Nov 30, 2016
This could need an update for .NET Standard 1.6 and maybe 2.0, even if it is not fully baked yet. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
mossyblog
Dec 7, 2016
The part that still concerns me is the vNext parts.. the fork in the road... let us pick on async/await ... now it's a pretty prolific thing to use in most "modern" .NET code today, however, Unity3D / WebGL, currently can't support this approach to multi-threading... now sure, one can argue "well, sux to be Unity3d and the world moves forward" however, all this does really is cap off a fork in the road, as in order for this to realistically work it needs some incentive or forcing function that encourages all ships to rise with the future tides in a uniform way (no boat gets left behind)... so how does one concede defeat on some areas where it just can't be brought forward due to technical or commercial limitations (lets for argument sake, assert Unity3D can't make task/parallel work because it conflicts with their IL2CPP output) on larger platform adoptees - such as Unity3D ...iOS etc.
The point is there will be commercial realities to face with the platform and how one triages that IF/ELSE statement is where I'm a little gun-shy from PCL abuse.
mossyblog
commented
Dec 7, 2016
•
edited
edited
The part that still concerns me is the vNext parts.. the fork in the road... let us pick on async/await ... now it's a pretty prolific thing to use in most "modern" .NET code today, however, Unity3D / WebGL, currently can't support this approach to multi-threading... now sure, one can argue "well, sux to be Unity3d and the world moves forward" however, all this does really is cap off a fork in the road, as in order for this to realistically work it needs some incentive or forcing function that encourages all ships to rise with the future tides in a uniform way (no boat gets left behind)... so how does one concede defeat on some areas where it just can't be brought forward due to technical or commercial limitations (lets for argument sake, assert Unity3D can't make task/parallel work because it conflicts with their IL2CPP output) on larger platform adoptees - such as Unity3D ...iOS etc. The point is there will be commercial realities to face with the platform and how one triages that IF/ELSE statement is where I'm a little gun-shy from PCL abuse. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
jorgensigvardsson
commented
Dec 7, 2016
I find this very clear and concise. Thanks! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
Jasonlhy
commented
Jan 13, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
stg609
commented
Feb 9, 2017
It makes more sense now! Thanks! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
devenshah
commented
Feb 10, 2017
Click! Click! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
peponeska
commented
Feb 15, 2017
What about netstandard2.0? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
Noctis-
commented
Mar 27, 2017
consider changing "choson" to "chosen" ? :) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
Kralizek
Apr 19, 2017
Really nice. I would suggest to use concrete classes to represent NetCoreApp10
, NetCoreApp11
and the several .NET Frameworks like Net46
and Net47
Kralizek
commented
Apr 19, 2017
Really nice. I would suggest to use concrete classes to represent |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
jsinh
commented
Jun 11, 2017
Makes sense, thanks! |
My initial expectation was that I need to use
#if
's to determine platform API availability. Is that the case?