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 Core + Existing Platforms - What Can We Expect? #973

Closed
shiftkey opened this Issue Feb 20, 2015 · 75 comments

Comments

Projects
None yet
@shiftkey

shiftkey commented Feb 20, 2015

I found myself watching a discussion between @davkean and @onovotny go down [start here] to better understand where .NET Core sits relative to existing platforms.

Because 140 characters is a terrible medium, let's keep this going here.

I'm still looking at supporting Windows 7 users for a while at least, so I'm curious what options are available around continuing to build Portable Class Libraries (the plans here seem to be that referencing other NuGet packages is how you can access additional BCL functionality in the future - correct me if I'm wrong) over targeting .NET Core directly.

What do we gain? What do we lose? And what expectations should we have in the short-term?

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Feb 20, 2015

Member

Thanks @shiftkey for bringing this conversation to a more long-format medium and great summary :).
What it boils down to is the disconnect between the apparent promise of .NET Core BCL being self-contained within apps and what kind of underlying platform support is needed. The way I read the .NET Core description, in the Windows Store/Windows Phone 8.1 section, it seems to imply that .NET Core will run there.

At the end of the day, as a library author, I still need to support .NET 4.5, Windows 8/8.1 WP8/8.1 Silverlight and Windows Phone 8.1 for at least a little while. To add a wrench, I also need to support the three Xamarin profiles (MonoAndroid, MonoTouch and Xamarin.iOS). Fortunately, the Xamarin profiles are 99% the same as the .NET 4.5 version.

As of last night, my current new understanding is that to that platform mix, I'll now need to add an additional ".NET Core" output. That new .NET Core output would be compatible with .NET 4.6, Windows 10 and ASPNet vNext. This does add an additional burden, though I suspect the code will be mostly similar to the existing Wpa81/Win81 code paths. Still means more #ifdefs and outputs though.

My initial understanding of .NET Core was that any "System.Runtime" platform would be supported. So that'd include Win8+, Wp8+ and Net45+. If that were possible, then Xamarin notwithstanding, I'd be thrilled to have a single .NET Core output that worked on all those platforms.

Member

onovotny commented Feb 20, 2015

Thanks @shiftkey for bringing this conversation to a more long-format medium and great summary :).
What it boils down to is the disconnect between the apparent promise of .NET Core BCL being self-contained within apps and what kind of underlying platform support is needed. The way I read the .NET Core description, in the Windows Store/Windows Phone 8.1 section, it seems to imply that .NET Core will run there.

At the end of the day, as a library author, I still need to support .NET 4.5, Windows 8/8.1 WP8/8.1 Silverlight and Windows Phone 8.1 for at least a little while. To add a wrench, I also need to support the three Xamarin profiles (MonoAndroid, MonoTouch and Xamarin.iOS). Fortunately, the Xamarin profiles are 99% the same as the .NET 4.5 version.

As of last night, my current new understanding is that to that platform mix, I'll now need to add an additional ".NET Core" output. That new .NET Core output would be compatible with .NET 4.6, Windows 10 and ASPNet vNext. This does add an additional burden, though I suspect the code will be mostly similar to the existing Wpa81/Win81 code paths. Still means more #ifdefs and outputs though.

My initial understanding of .NET Core was that any "System.Runtime" platform would be supported. So that'd include Win8+, Wp8+ and Net45+. If that were possible, then Xamarin notwithstanding, I'd be thrilled to have a single .NET Core output that worked on all those platforms.

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean Feb 20, 2015

Member

Let's clarify a few things.

  • .NET Core is the framework for the next version of both Windows 8.1 and Windows Phone 8.1, ie Windows 10. Existing Windows 8.1 and/or Phone 8.1 libraries will be able to consumed by .NET Core with zero changes. When running on Windows Devices, .NET Core will sit on top of the .NET Native runtime. You shouldn't be treating .NET Core as a new platform, but just as a new version of these existing platforms.
  • .NET Core is also the framework for the new ASP.NET 5 Core stack. This stack will run cross-platform across Windows, Mac and Linux. System.Runtime-based portable binaries will be able to be consumed by .NET Core with zero changes. When running on the server, .NET Core will sit on top of the CoreCLR runtime.
  • .NET Core will be a highly componentized "app-local" stack and that will ship entirely on NuGet. Every assembly will be in its own versionable package and, with exception to those that fall into the Runtime Adaption Layer, are independently upgradable.
  • While .NET Core's assemblies are independently versionable/upgradable, we suspect most developers will opt into what we're calling a .NET Core distribution; basically, a collection of well tested, fully supported set of assemblies that we know work well together. By default, projects in Visual Studio will be (but not forced into) targeting these distributions (which will already be on the box). We'll probably release distributions 2 - 4 times a year.
  • Portable will still play a place in this new world. It will still be the bridge between all the platforms (new and old). You'll be able to target .NET 4.5 and Windows 10, or .NET 4.5 and ASP.NET Core for example. When targeting only the ".NET Core" targets, instead of profiles representing the common surface area, developers will consume NuGet packages, and unlike profiles which are fixed and can never change, they will be able to upgrade individual packages to higher versions to get additional API when we release it.
Member

davkean commented Feb 20, 2015

Let's clarify a few things.

  • .NET Core is the framework for the next version of both Windows 8.1 and Windows Phone 8.1, ie Windows 10. Existing Windows 8.1 and/or Phone 8.1 libraries will be able to consumed by .NET Core with zero changes. When running on Windows Devices, .NET Core will sit on top of the .NET Native runtime. You shouldn't be treating .NET Core as a new platform, but just as a new version of these existing platforms.
  • .NET Core is also the framework for the new ASP.NET 5 Core stack. This stack will run cross-platform across Windows, Mac and Linux. System.Runtime-based portable binaries will be able to be consumed by .NET Core with zero changes. When running on the server, .NET Core will sit on top of the CoreCLR runtime.
  • .NET Core will be a highly componentized "app-local" stack and that will ship entirely on NuGet. Every assembly will be in its own versionable package and, with exception to those that fall into the Runtime Adaption Layer, are independently upgradable.
  • While .NET Core's assemblies are independently versionable/upgradable, we suspect most developers will opt into what we're calling a .NET Core distribution; basically, a collection of well tested, fully supported set of assemblies that we know work well together. By default, projects in Visual Studio will be (but not forced into) targeting these distributions (which will already be on the box). We'll probably release distributions 2 - 4 times a year.
  • Portable will still play a place in this new world. It will still be the bridge between all the platforms (new and old). You'll be able to target .NET 4.5 and Windows 10, or .NET 4.5 and ASP.NET Core for example. When targeting only the ".NET Core" targets, instead of profiles representing the common surface area, developers will consume NuGet packages, and unlike profiles which are fixed and can never change, they will be able to upgrade individual packages to higher versions to get additional API when we release it.
@n8ohu

This comment has been minimized.

Show comment
Hide comment
@n8ohu

n8ohu Feb 20, 2015

@davkean I'm going to ask this here, since it's the best option I have; does this mean that the planned Windows 10 release for the Raspberry Pi 2 will support .NET Native apps?

n8ohu commented Feb 20, 2015

@davkean I'm going to ask this here, since it's the best option I have; does this mean that the planned Windows 10 release for the Raspberry Pi 2 will support .NET Native apps?

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean Feb 20, 2015

Member

@n8ohu I can't answer that. :)

Member

davkean commented Feb 20, 2015

@n8ohu I can't answer that. :)

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Feb 20, 2015

Member

@davkean Ok, thanks for the clarification. So to restate:

  • Existing PCL's that target Wpa81+Win81 will work on Win10 (but not ASPNet vNext)
  • We can also then create a new "System.Runtime" .NET Core dll that will target Win10 + AspNet vNext (and should be mostly the same code path as Wpa81/Win81)

Is that accurate?

Member

onovotny commented Feb 20, 2015

@davkean Ok, thanks for the clarification. So to restate:

  • Existing PCL's that target Wpa81+Win81 will work on Win10 (but not ASPNet vNext)
  • We can also then create a new "System.Runtime" .NET Core dll that will target Win10 + AspNet vNext (and should be mostly the same code path as Wpa81/Win81)

Is that accurate?

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean Feb 20, 2015

Member

Every System.Runtime-based library today that does not use WinRT will run on .NET Core everywhere. If you used WinRT, you will run on platforms with WinRT.

Member

davkean commented Feb 20, 2015

Every System.Runtime-based library today that does not use WinRT will run on .NET Core everywhere. If you used WinRT, you will run on platforms with WinRT.

@ellismg

This comment has been minimized.

Show comment
Hide comment
@ellismg

ellismg Feb 21, 2015

Contributor

It would be nice if all this information was captured on the wiki somewhere. Care to take a shot at writing up a FAQ and putting it on the Wiki, Dave?

Contributor

ellismg commented Feb 21, 2015

It would be nice if all this information was captured on the wiki somewhere. Care to take a shot at writing up a FAQ and putting it on the Wiki, Dave?

@am11

This comment has been minimized.

Show comment
Hide comment
@am11

am11 Feb 22, 2015

Contributor

@davkean,

First of all thanks for the explanation. I have heard and read many varied interpretations of .NET Core corefx; its purpose and its value in light of existing full-scaled .NET Framework. You have nailed it by giving it straight! :)

Regarding these points:

  • When running on Windows Devices, .NET Core will sit on top of the .NET Native
  • When running on the server, .NET Core will sit on top of the CoreCLR runtime.

If .NET Native is defined as "some machinery which will compile and optimise your .NET code to super fast machine code", then how is it analogous or related to CoreCLR? Shouldn't the code that is compiled with .NET Native runtime totally bypass <Any>CLR? Or does that mean .NET Native will not be available on Servers?

Contributor

am11 commented Feb 22, 2015

@davkean,

First of all thanks for the explanation. I have heard and read many varied interpretations of .NET Core corefx; its purpose and its value in light of existing full-scaled .NET Framework. You have nailed it by giving it straight! :)

Regarding these points:

  • When running on Windows Devices, .NET Core will sit on top of the .NET Native
  • When running on the server, .NET Core will sit on top of the CoreCLR runtime.

If .NET Native is defined as "some machinery which will compile and optimise your .NET code to super fast machine code", then how is it analogous or related to CoreCLR? Shouldn't the code that is compiled with .NET Native runtime totally bypass <Any>CLR? Or does that mean .NET Native will not be available on Servers?

@xanather

This comment has been minimized.

Show comment
Hide comment
@xanather

xanather Feb 22, 2015

@davkean This is what I think about .NET Native after reading about it (might not be 100% correct):

When compiling with .NET Native the MSIL is converted to machine code for the target platform. So yes there wouldn't be an AnyCPU option when compiling for .NET Native. I like to think of it simply as a pre-jitted program though I'm sure its more complex than that. CoreCLR runtime would still be running within the compiled .NET Native project (though once again - probably in a slightly different form).

Right now .NET Native is limited to Windows Store Apps since its part of the deployment process for it, if it ends up being supported on desktops as classical programs then I don't see why they couldn't run within servers.

xanather commented Feb 22, 2015

@davkean This is what I think about .NET Native after reading about it (might not be 100% correct):

When compiling with .NET Native the MSIL is converted to machine code for the target platform. So yes there wouldn't be an AnyCPU option when compiling for .NET Native. I like to think of it simply as a pre-jitted program though I'm sure its more complex than that. CoreCLR runtime would still be running within the compiled .NET Native project (though once again - probably in a slightly different form).

Right now .NET Native is limited to Windows Store Apps since its part of the deployment process for it, if it ends up being supported on desktops as classical programs then I don't see why they couldn't run within servers.

@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Feb 23, 2015

Contributor

There's some very good information in this thread, but as @ellismg suggests, it really needs to be available in a clear, simple format, understandable to people as simple minded/stubborn/impatient as myself. At the moment I'm still bamboozled by all the different platform names that are being thrown about and I once I do understand part of it, I tend to lose the information fairly quickly and have to re-learn all over again. E.g. a diagramatic representation of @davkean's comment would be ideal.

Contributor

adamralph commented Feb 23, 2015

There's some very good information in this thread, but as @ellismg suggests, it really needs to be available in a clear, simple format, understandable to people as simple minded/stubborn/impatient as myself. At the moment I'm still bamboozled by all the different platform names that are being thrown about and I once I do understand part of it, I tend to lose the information fairly quickly and have to re-learn all over again. E.g. a diagramatic representation of @davkean's comment would be ideal.

@dsplaisted

This comment has been minimized.

Show comment
Hide comment
@dsplaisted

dsplaisted Feb 23, 2015

Member

Check out this diagram from the Introducing .NET Core blog post:

.NET Core diagram

In that diagram, the "Unified BCL" and "Runtime adaption layer" will mostly be in the corefx repo. The CoreCLR is in the coreclr repo. .NET Native includes tooling to compile IL code into native code, as well as the runtime support needed for that.

The CoreCLR runtime (eg the JIT, garbage collector, type system) will not be used by .NET Native. However, for most of the libraries in the BCL (collections, LINQ, File I/O, networking, etc), the same DLLs will be used for .NET Native as for CoreCLR.

.NET Native will produce a native, architecture-specific binary, but the MSIL input to it can be targeted at AnyCPU.

@am11 @xanather @adamralph I hope this helps make things a bit clearer.

Member

dsplaisted commented Feb 23, 2015

Check out this diagram from the Introducing .NET Core blog post:

.NET Core diagram

In that diagram, the "Unified BCL" and "Runtime adaption layer" will mostly be in the corefx repo. The CoreCLR is in the coreclr repo. .NET Native includes tooling to compile IL code into native code, as well as the runtime support needed for that.

The CoreCLR runtime (eg the JIT, garbage collector, type system) will not be used by .NET Native. However, for most of the libraries in the BCL (collections, LINQ, File I/O, networking, etc), the same DLLs will be used for .NET Native as for CoreCLR.

.NET Native will produce a native, architecture-specific binary, but the MSIL input to it can be targeted at AnyCPU.

@am11 @xanather @adamralph I hope this helps make things a bit clearer.

@benaadams

This comment has been minimized.

Show comment
Hide comment
@benaadams

benaadams Feb 23, 2015

Collaborator

RyuJIT is now making use of SIMD; will .NET Native also compile using SIMD optimisations?

Collaborator

benaadams commented Feb 23, 2015

RyuJIT is now making use of SIMD; will .NET Native also compile using SIMD optimisations?

@dsplaisted

This comment has been minimized.

Show comment
Hide comment
@dsplaisted

dsplaisted Feb 23, 2015

Member

@benaadams I'm pretty sure that's the plan but I don't know the specifics. Any comment about SIMD and .NET native @mellinoe?

Member

dsplaisted commented Feb 23, 2015

@benaadams I'm pretty sure that's the plan but I don't know the specifics. Any comment about SIMD and .NET native @mellinoe?

@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Feb 24, 2015

Contributor

@dsplaisted thanks for the diagram. @davkean does link to it in his comment but it really only tells a small part of the story. There are lots of other terms mentioned which are not captured so I think there just needs to be something similar, but more complete, a true canonical reference for all this stuff. At the moment it requires forensics to get the whole picture, e.g. trawling through discussions such as this one.

Contributor

adamralph commented Feb 24, 2015

@dsplaisted thanks for the diagram. @davkean does link to it in his comment but it really only tells a small part of the story. There are lots of other terms mentioned which are not captured so I think there just needs to be something similar, but more complete, a true canonical reference for all this stuff. At the moment it requires forensics to get the whole picture, e.g. trawling through discussions such as this one.

@LightVolk

This comment has been minimized.

Show comment
Hide comment
@LightVolk

LightVolk Feb 24, 2015

.NET Native will produce a native, architecture-specific binary, but the MSIL input to it can be targeted at AnyCPU.

So, it uses only for Win 8 App? Will it be on Win7-like desktop apps?

LightVolk commented Feb 24, 2015

.NET Native will produce a native, architecture-specific binary, but the MSIL input to it can be targeted at AnyCPU.

So, it uses only for Win 8 App? Will it be on Win7-like desktop apps?

@RichiCoder1

This comment has been minimized.

Show comment
Hide comment
@RichiCoder1

RichiCoder1 Feb 24, 2015

@LightVolk my understanding is that the focus is on getting Win8/10 app compilation solid, and then considering other platforms. So it could be used for Win7, but there's no guarantee or solid plans at this time.

@benaadams @dsplaisted since .NET native uses Visual C++'s compiler under the covers, there should technically be no reason why it can't take advantage of SIMD automatically, as well as a number of other optimizations. I think the focus is on startup times and portability right now though.

RichiCoder1 commented Feb 24, 2015

@LightVolk my understanding is that the focus is on getting Win8/10 app compilation solid, and then considering other platforms. So it could be used for Win7, but there's no guarantee or solid plans at this time.

@benaadams @dsplaisted since .NET native uses Visual C++'s compiler under the covers, there should technically be no reason why it can't take advantage of SIMD automatically, as well as a number of other optimizations. I think the focus is on startup times and portability right now though.

@benaadams

This comment has been minimized.

Show comment
Hide comment
@benaadams

benaadams Feb 24, 2015

Collaborator

@RichiCoder1 up for the automatic; is more specifically System.Numerics.Vectors which is explicit SIMD intrinsic use rather than auto-vectorisation

Collaborator

benaadams commented Feb 24, 2015

@RichiCoder1 up for the automatic; is more specifically System.Numerics.Vectors which is explicit SIMD intrinsic use rather than auto-vectorisation

@RichiCoder1

This comment has been minimized.

Show comment
Hide comment
@RichiCoder1

RichiCoder1 Feb 24, 2015

@benaadams Yup, I understand. Theoretically there's no reason why they couldn't, but it might not be a priority just yet. Sadly we haven't gotten a comprehensive update on Native since last year. I'm hoping for something before //Build, but we'll probably be waiting till then.

RichiCoder1 commented Feb 24, 2015

@benaadams Yup, I understand. Theoretically there's no reason why they couldn't, but it might not be a priority just yet. Sadly we haven't gotten a comprehensive update on Native since last year. I'm hoping for something before //Build, but we'll probably be waiting till then.

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean Feb 24, 2015

Member

I can have a crack at putting this in the wiki. @adamralph can you help me understand what you think is missing or what areas/things you would like us to explain more about? We have so much history and background around all this; I'd like to focus on things that are top of mind.

Member

davkean commented Feb 24, 2015

I can have a crack at putting this in the wiki. @adamralph can you help me understand what you think is missing or what areas/things you would like us to explain more about? We have so much history and background around all this; I'd like to focus on things that are top of mind.

@akoeplinger

This comment has been minimized.

Show comment
Hide comment
@akoeplinger

akoeplinger Feb 24, 2015

Member

@davkean A common complaint from library authors is that .NET Core seems like "yet another target to support" ([1], [2]), would be cool to address this and show why .NET Core is different and how the whole story looks from a library author's point of view.

Member

akoeplinger commented Feb 24, 2015

@davkean A common complaint from library authors is that .NET Core seems like "yet another target to support" ([1], [2]), would be cool to address this and show why .NET Core is different and how the whole story looks from a library author's point of view.

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean Feb 24, 2015

Member

Yep, there seems to be a little bit FUD being spread around due to the lack of real concrete information. While we've always had a mechanism to target the platforms in a uniform way (via these reference assemblies we called "contracts"), we tooled it badly and forced every library developer to think about and hence build for each platform individually.

.NET Core is about unifying the surface areas across the different programming models and we're putting our money where our mouth is:

  • All of our .NET Core libraries (with exception to the runtime adaption layers) are themselves built on top of the same surface area that 3rd party developers use. No more InternalVisibleTo, or private handshakes between libraries; only public extension points and APIs can be used.
  • A bunch of internal partners have started building on top of the surface area to simplify their targeting experience including Roslyn, EntityFramework, PowerShell and lots of components within Windows.
  • Windows and .NET's tests and test infrastructure built on top of it to simplify testing across all the different Windows SKUs
Member

davkean commented Feb 24, 2015

Yep, there seems to be a little bit FUD being spread around due to the lack of real concrete information. While we've always had a mechanism to target the platforms in a uniform way (via these reference assemblies we called "contracts"), we tooled it badly and forced every library developer to think about and hence build for each platform individually.

.NET Core is about unifying the surface areas across the different programming models and we're putting our money where our mouth is:

  • All of our .NET Core libraries (with exception to the runtime adaption layers) are themselves built on top of the same surface area that 3rd party developers use. No more InternalVisibleTo, or private handshakes between libraries; only public extension points and APIs can be used.
  • A bunch of internal partners have started building on top of the surface area to simplify their targeting experience including Roslyn, EntityFramework, PowerShell and lots of components within Windows.
  • Windows and .NET's tests and test infrastructure built on top of it to simplify testing across all the different Windows SKUs
@cdrnet

This comment has been minimized.

Show comment
Hide comment
@cdrnet

cdrnet Feb 24, 2015

Yes, please do show in more detail how the story looks from a library author's point of view, as suggested by @akoeplinger.

For example, I maintain a library which currently has distinct builds for .Net 3.5 (sic!), 4.0, 4.5 and 3 PCL profiles in the NuGet packages and a lot of ifdef's in the source code to try to cover them all.

It's great that it will unify the surface areas of all kind of platforms, yet as a library developer I understand I need to support specific development targets, not platforms. The surface area I care about is not Windows 8.1 or 10 on PCs, Tablets, Phones and Raspberry PIs. The surface area I need to target is, in my case, the set of .Net 3.5, .Net 4.0, .Net 4.5, PCL profiles 47, 78 and 259, and now probably something else for .Net Core and ASP vNext ("yet another target to support").

So, without the FUD, what exactly does .NET Core mean to me and my library?

cdrnet commented Feb 24, 2015

Yes, please do show in more detail how the story looks from a library author's point of view, as suggested by @akoeplinger.

For example, I maintain a library which currently has distinct builds for .Net 3.5 (sic!), 4.0, 4.5 and 3 PCL profiles in the NuGet packages and a lot of ifdef's in the source code to try to cover them all.

It's great that it will unify the surface areas of all kind of platforms, yet as a library developer I understand I need to support specific development targets, not platforms. The surface area I care about is not Windows 8.1 or 10 on PCs, Tablets, Phones and Raspberry PIs. The surface area I need to target is, in my case, the set of .Net 3.5, .Net 4.0, .Net 4.5, PCL profiles 47, 78 and 259, and now probably something else for .Net Core and ASP vNext ("yet another target to support").

So, without the FUD, what exactly does .NET Core mean to me and my library?

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean Feb 24, 2015

Member

@cdrnet The FUD I was referring to, is that ".NET Core" is another platform. It's not, it's the continuation of the existing platforms. For example, your PCL's already targeting "System.Runtime" (in this case "78", and "259") are already supported on that platform (and hence will work in ASP.NET vNext and Windows 10).

In the short term, .NET Core will not change the world for libraries.
In the long term, however, .NET Core will completely change the way libraries are built for the .NET platform.

Today, when I start a new library, I need to make the decision between targeting older platforms vs. making use of API only available in the newer platforms (or live in both worlds like yourself, where you build multiple times).

Tomorrow, for .NET Core platforms, you no longer need to make that decision. Because the framework libraries (and runtime) are carried with the application, the versions of these things are no longer fixed. If JSON.NET uses a higher version of System.Collections.dll than what my application uses, NuGet will automatically pull the higher version when I install JSON.NET, and it gets deployed along with my application.

@cdrnet Side note, I'd like to understand why you need to target all the portable profiles that you do, for example what's the difference between your project targeting 259 and 78?

Member

davkean commented Feb 24, 2015

@cdrnet The FUD I was referring to, is that ".NET Core" is another platform. It's not, it's the continuation of the existing platforms. For example, your PCL's already targeting "System.Runtime" (in this case "78", and "259") are already supported on that platform (and hence will work in ASP.NET vNext and Windows 10).

In the short term, .NET Core will not change the world for libraries.
In the long term, however, .NET Core will completely change the way libraries are built for the .NET platform.

Today, when I start a new library, I need to make the decision between targeting older platforms vs. making use of API only available in the newer platforms (or live in both worlds like yourself, where you build multiple times).

Tomorrow, for .NET Core platforms, you no longer need to make that decision. Because the framework libraries (and runtime) are carried with the application, the versions of these things are no longer fixed. If JSON.NET uses a higher version of System.Collections.dll than what my application uses, NuGet will automatically pull the higher version when I install JSON.NET, and it gets deployed along with my application.

@cdrnet Side note, I'd like to understand why you need to target all the portable profiles that you do, for example what's the difference between your project targeting 259 and 78?

@am11

This comment has been minimized.

Show comment
Hide comment
@am11

am11 Feb 24, 2015

Contributor

@davkean, from deployment perspective, is it like:

  • we will only need to have .NET Core installed on the end-user's system (nix, mac, win), since everything else will be bundled with the app?
  • we would not need to have any .NET-related entity (runtimes, frameworks, cores and so on..) installed on the client machine, since everything including .NET Core will be bundled with the app?
Contributor

am11 commented Feb 24, 2015

@davkean, from deployment perspective, is it like:

  • we will only need to have .NET Core installed on the end-user's system (nix, mac, win), since everything else will be bundled with the app?
  • we would not need to have any .NET-related entity (runtimes, frameworks, cores and so on..) installed on the client machine, since everything including .NET Core will be bundled with the app?
@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean Feb 24, 2015

Member

@am11 It's the later. .NET Core and the runtime is bundled with the application.

Member

davkean commented Feb 24, 2015

@am11 It's the later. .NET Core and the runtime is bundled with the application.

@am11

This comment has been minimized.

Show comment
Hide comment
@am11

am11 Feb 24, 2015

Contributor

@davkean, thanks! 👍

Contributor

am11 commented Feb 24, 2015

@davkean, thanks! 👍

@cdrnet

This comment has been minimized.

Show comment
Hide comment
@cdrnet

cdrnet Feb 24, 2015

@davkean thanks for the clarification!
@davkean In practice I actually target even more profiles: 7, 47, 78, 259 and 328. The main reasons are:

  • I want to leverage System.Numerics where available (7, 47) - otherwise (78,259,328) I need to bring my own double precision Complex number type, among others.
  • Some profiles require .Net 4.5 style reflection (7,78,259), others .Net 4.0 style (47,328).
  • I want to support all platforms & targets supported by F# as good as I can and FSharp.Core explicitly ships with the first four of these targets. It is possible that I could indeed merge 78 and 259 though as I use the same compilation symbols/flags for them.

cdrnet commented Feb 24, 2015

@davkean thanks for the clarification!
@davkean In practice I actually target even more profiles: 7, 47, 78, 259 and 328. The main reasons are:

  • I want to leverage System.Numerics where available (7, 47) - otherwise (78,259,328) I need to bring my own double precision Complex number type, among others.
  • Some profiles require .Net 4.5 style reflection (7,78,259), others .Net 4.0 style (47,328).
  • I want to support all platforms & targets supported by F# as good as I can and FSharp.Core explicitly ships with the first four of these targets. It is possible that I could indeed merge 78 and 259 though as I use the same compilation symbols/flags for them.
@cdrnet

This comment has been minimized.

Show comment
Hide comment
@cdrnet

cdrnet Feb 25, 2015

This may be relevant: Understanding .NET 2015 (posted today)

cdrnet commented Feb 25, 2015

This may be relevant: Understanding .NET 2015 (posted today)

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Jun 10, 2015

Member

Old post, but hopefully my latest blog can help clarify things, or so I hope!
http://oren.codes/2015/06/09/pcls-net-core-dnx-and-uwp/

Member

onovotny commented Jun 10, 2015

Old post, but hopefully my latest blog can help clarify things, or so I hope!
http://oren.codes/2015/06/09/pcls-net-core-dnx-and-uwp/

@iamjasonp

This comment has been minimized.

Show comment
Hide comment
@iamjasonp
Member

iamjasonp commented Jun 10, 2015

👍 @onovotny!

@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Jun 13, 2015

Contributor

@onovotny thanks, that definitely helps!

Contributor

adamralph commented Jun 13, 2015

@onovotny thanks, that definitely helps!

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jul 7, 2015

are you kidding me..... what a complete Fubar

ghost commented Jul 7, 2015

are you kidding me..... what a complete Fubar

@MelbourneDeveloper

This comment has been minimized.

Show comment
Hide comment
@MelbourneDeveloper

MelbourneDeveloper Sep 23, 2016

I'd just like to mention Silverlight (Browser based - not phone based).

I know that Microsoft wants to distance itself from Silverlight, and I understand why. But, if .NET Standard were available for Silverlight, this would help us out with the process of moving off Silverlight immensely.

Just to explain...

We currently have an app with a .NET Framework WCF back end, and a Silverlight front end. We are moving to a .NET back end (hopefully .NET Core, maybe REST, maybe WebSockets), with the front ends being UWP, Android, and iOS. We have moved most of our code in to a .NET Standard library which works across, .NET Core Android, probably iOS, and UWP. If this library also worked on Silverlight, we'd have the majority of our infrastructure compiled in to just one assembly type: .NET Standard.

Right now, we still have to at least support Silverlight, and .NET Standard, which is still a headache. If we could get these things together, we would really taking a leap forward.

Could we please get .NET Standard for Silverlight?

MelbourneDeveloper commented Sep 23, 2016

I'd just like to mention Silverlight (Browser based - not phone based).

I know that Microsoft wants to distance itself from Silverlight, and I understand why. But, if .NET Standard were available for Silverlight, this would help us out with the process of moving off Silverlight immensely.

Just to explain...

We currently have an app with a .NET Framework WCF back end, and a Silverlight front end. We are moving to a .NET back end (hopefully .NET Core, maybe REST, maybe WebSockets), with the front ends being UWP, Android, and iOS. We have moved most of our code in to a .NET Standard library which works across, .NET Core Android, probably iOS, and UWP. If this library also worked on Silverlight, we'd have the majority of our infrastructure compiled in to just one assembly type: .NET Standard.

Right now, we still have to at least support Silverlight, and .NET Standard, which is still a headache. If we could get these things together, we would really taking a leap forward.

Could we please get .NET Standard for Silverlight?

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Sep 23, 2016

Member

@MelbourneDeveloper Would cross-compiling make this easier?

Member

onovotny commented Sep 23, 2016

@MelbourneDeveloper Would cross-compiling make this easier?

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Sep 23, 2016

Could we please get .NET Standard for Silverlight?

FWIW, nearly 4500 votes have asked for basically just that here, @MelbourneDeveloper:
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo

Although at this point I doubt it would be Silverlight per se (they are really committed to sunsetting it out by 2021), but a .NET profile not unlike Xamarin's that works in the browser, probably via WebAssembly is probably much more realistic.

All conjecture of course, but you are not alone in wanting this. I myself invested five years of my life in Silverlight and have been pawing at it ever sense it was put to pasture. Heck, the above mentioned vote is a result of exactly that!

Mike-EEE commented Sep 23, 2016

Could we please get .NET Standard for Silverlight?

FWIW, nearly 4500 votes have asked for basically just that here, @MelbourneDeveloper:
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo

Although at this point I doubt it would be Silverlight per se (they are really committed to sunsetting it out by 2021), but a .NET profile not unlike Xamarin's that works in the browser, probably via WebAssembly is probably much more realistic.

All conjecture of course, but you are not alone in wanting this. I myself invested five years of my life in Silverlight and have been pawing at it ever sense it was put to pasture. Heck, the above mentioned vote is a result of exactly that!

@MelbourneDeveloper

This comment has been minimized.

Show comment
Hide comment
@MelbourneDeveloper

MelbourneDeveloper Sep 23, 2016

@onovotny

Would cross-compiling make this easier?

Sorry, I should probably clarify a bit here. My understanding is that .NET Core is the runtime environment. .NET Standard is 2 things: versioned standard sets of APIs, and a DLL format that targets multiple platforms. I.e. cross compilation. Is this correct? Is this what you mean by cross-compilation?

What I was asking for was for Silverlight to accept .NET Standard assemblies as references. But, basically, I'd just like a way to be able to share the structure of a given project with Silverlight. So, if Silverlight won't accept a .NET Standard DLL, at least let me take my existing .NET Standard Project, and compile it to a Silverlight DLL. Does that make sense?

@Mike-EEE

FWIW, nearly 4500 votes have asked for basically just that here, @MelbourneDeveloper:
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo

I just voted this up. But at the same time, isn't what is being asked for here .NET Standard?

All conjecture of course, but you are not alone in wanting this. I myself invested five years of my life in Silverlight and have been pawing at it ever sense it was put to pasture. Heck, the above mentioned vote is a result of exactly that!

It makes me feel so good to know that I am not alone here. I understand the reasons for sunsetting Silverlight. But, it doesn't have to feel like being crushed by a gorilla when trying to make the transition to the next set of platforms.

MelbourneDeveloper commented Sep 23, 2016

@onovotny

Would cross-compiling make this easier?

Sorry, I should probably clarify a bit here. My understanding is that .NET Core is the runtime environment. .NET Standard is 2 things: versioned standard sets of APIs, and a DLL format that targets multiple platforms. I.e. cross compilation. Is this correct? Is this what you mean by cross-compilation?

What I was asking for was for Silverlight to accept .NET Standard assemblies as references. But, basically, I'd just like a way to be able to share the structure of a given project with Silverlight. So, if Silverlight won't accept a .NET Standard DLL, at least let me take my existing .NET Standard Project, and compile it to a Silverlight DLL. Does that make sense?

@Mike-EEE

FWIW, nearly 4500 votes have asked for basically just that here, @MelbourneDeveloper:
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo

I just voted this up. But at the same time, isn't what is being asked for here .NET Standard?

All conjecture of course, but you are not alone in wanting this. I myself invested five years of my life in Silverlight and have been pawing at it ever sense it was put to pasture. Heck, the above mentioned vote is a result of exactly that!

It makes me feel so good to know that I am not alone here. I understand the reasons for sunsetting Silverlight. But, it doesn't have to feel like being crushed by a gorilla when trying to make the transition to the next set of platforms.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Sep 23, 2016

I just voted this up. But at the same time, isn't what is being asked for here .NET Standard?

I don't know... is it? LOL! Silverlight is a trigger word, what can I say,

But, it doesn't have to feel like being crushed by a gorilla when trying to make the transition to the next set of platforms.

I see you've met UWP. 😄

Mike-EEE commented Sep 23, 2016

I just voted this up. But at the same time, isn't what is being asked for here .NET Standard?

I don't know... is it? LOL! Silverlight is a trigger word, what can I say,

But, it doesn't have to feel like being crushed by a gorilla when trying to make the transition to the next set of platforms.

I see you've met UWP. 😄

@SamuelEnglard

This comment has been minimized.

Show comment
Hide comment
@SamuelEnglard

SamuelEnglard Sep 23, 2016

Collaborator

@MelbourneDeveloper you're half right there .NET Standard is a versioned set of standard set of APIs. It is not a DLL format. The DLL format is actually the same for the different flavors since that's part of what makes .NET ".NET".

To make Silverlight part of .NET Standard we would have to find a version of the Standard that is satisfied by Silverlight 5. Once that's done MOST of the work is done.

Collaborator

SamuelEnglard commented Sep 23, 2016

@MelbourneDeveloper you're half right there .NET Standard is a versioned set of standard set of APIs. It is not a DLL format. The DLL format is actually the same for the different flavors since that's part of what makes .NET ".NET".

To make Silverlight part of .NET Standard we would have to find a version of the Standard that is satisfied by Silverlight 5. Once that's done MOST of the work is done.

@MelbourneDeveloper

This comment has been minimized.

Show comment
Hide comment
@MelbourneDeveloper

MelbourneDeveloper Sep 25, 2016

It is not a DLL format. The DLL format is actually the same for the different flavors since that's part of what makes .NET ".NET".

I find it hard to get my head around this. Why is it then that you can take a PCL project, and switch it over to target .NET Standard?

MelbourneDeveloper commented Sep 25, 2016

It is not a DLL format. The DLL format is actually the same for the different flavors since that's part of what makes .NET ".NET".

I find it hard to get my head around this. Why is it then that you can take a PCL project, and switch it over to target .NET Standard?

@SamuelEnglard

This comment has been minimized.

Show comment
Hide comment
@SamuelEnglard

SamuelEnglard Sep 26, 2016

Collaborator

Going to try and explain this without getting too into it.

.NET DLLs are formatted according to ECMA-335 (Better known as the Common Language Infrastructure). This format is true across all platforms we call .NET; Full Framework, Core, Xamarin, Mono, Silverlight, etc.

The reason you couldn't use a DLL compiled against one platform with another was that the format didn't specify APIs (generally speaking). So while they could all read the DLL you'd run into issues of class XYZ being in namespace A.B.C on one platform and in namespace D.E.F on another, if it existed at all.

PCLs "solved" this by doing two things:

  1. They used Type Forwarding so that even though you wrote your code expecting class XYZ in namespace A.B.C, it could be found on platforms that had it elsewhere.
  2. It limited what APIs you could use to the lowest common set shared by all the platforms you wanted.

Taking a PCL and converting it to a .NET Standard project is not a recompile because of output format but because of the meta data included (Type Forwarding particularly).

Collaborator

SamuelEnglard commented Sep 26, 2016

Going to try and explain this without getting too into it.

.NET DLLs are formatted according to ECMA-335 (Better known as the Common Language Infrastructure). This format is true across all platforms we call .NET; Full Framework, Core, Xamarin, Mono, Silverlight, etc.

The reason you couldn't use a DLL compiled against one platform with another was that the format didn't specify APIs (generally speaking). So while they could all read the DLL you'd run into issues of class XYZ being in namespace A.B.C on one platform and in namespace D.E.F on another, if it existed at all.

PCLs "solved" this by doing two things:

  1. They used Type Forwarding so that even though you wrote your code expecting class XYZ in namespace A.B.C, it could be found on platforms that had it elsewhere.
  2. It limited what APIs you could use to the lowest common set shared by all the platforms you wanted.

Taking a PCL and converting it to a .NET Standard project is not a recompile because of output format but because of the meta data included (Type Forwarding particularly).

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Sep 26, 2016

Nice work, @SamuelEnglard. Looks like a nice blog post was also posted today to (hopefully) answer some questions, as well: https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

Mike-EEE commented Sep 26, 2016

Nice work, @SamuelEnglard. Looks like a nice blog post was also posted today to (hopefully) answer some questions, as well: https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

@SamuelEnglard

This comment has been minimized.

Show comment
Hide comment
@SamuelEnglard

SamuelEnglard Sep 26, 2016

Collaborator

@Mike-EEE thanks! Wish I could have just pointed at that!

Collaborator

SamuelEnglard commented Sep 26, 2016

@Mike-EEE thanks! Wish I could have just pointed at that!

@MelbourneDeveloper

This comment has been minimized.

Show comment
Hide comment
@MelbourneDeveloper

MelbourneDeveloper Sep 26, 2016

@SamuelEnglard

Nice explanation! Just so you know, I am posting your explanation here:
http://stackoverflow.com/questions/39050911/net-standard-net-core-pcl

I think to sum up, the situation is a lot simpler than I thought.

CLI = DLL format across the board. That's why we can open all DLLs in ILDasm
.Net Standard = standard set of APIs so that anything that implements these APIs is able to leverage .NET standard.

So, targeting a PCL Vs. .NET Standard only differs in the sense that types and namespace pointers are standardized in a different way.

MelbourneDeveloper commented Sep 26, 2016

@SamuelEnglard

Nice explanation! Just so you know, I am posting your explanation here:
http://stackoverflow.com/questions/39050911/net-standard-net-core-pcl

I think to sum up, the situation is a lot simpler than I thought.

CLI = DLL format across the board. That's why we can open all DLLs in ILDasm
.Net Standard = standard set of APIs so that anything that implements these APIs is able to leverage .NET standard.

So, targeting a PCL Vs. .NET Standard only differs in the sense that types and namespace pointers are standardized in a different way.

@SamuelEnglard

This comment has been minimized.

Show comment
Hide comment
@SamuelEnglard

SamuelEnglard Sep 27, 2016

Collaborator

CLI = DLL format across the board. That's why we can open all DLLs in ILDasm
.Net Standard = standard set of APIs so that anything that implements these APIs is able to leverage .NET standard.

Exactly

So, targeting a PCL Vs. .NET Standard only differs in the sense that types and namespace pointers are standardized in a different way.

Close. PCL actually defined how it worked. .NET Standard is just a list of APIs and what they do, kind of like Header files in C++.

Collaborator

SamuelEnglard commented Sep 27, 2016

CLI = DLL format across the board. That's why we can open all DLLs in ILDasm
.Net Standard = standard set of APIs so that anything that implements these APIs is able to leverage .NET standard.

Exactly

So, targeting a PCL Vs. .NET Standard only differs in the sense that types and namespace pointers are standardized in a different way.

Close. PCL actually defined how it worked. .NET Standard is just a list of APIs and what they do, kind of like Header files in C++.

@akoeplinger

This comment has been minimized.

Show comment
Hide comment
@akoeplinger

akoeplinger Sep 27, 2016

Member

One small correction: it's CIL (Common Intermediate Language) or just IL, not CLI.

Member

akoeplinger commented Sep 27, 2016

One small correction: it's CIL (Common Intermediate Language) or just IL, not CLI.

@SamuelEnglard

This comment has been minimized.

Show comment
Hide comment
@SamuelEnglard

SamuelEnglard Sep 27, 2016

Collaborator

@akoeplinger I was referencing the CLI since the DLL format is more than just CIL (of particular interest here being the binary serialization).

Collaborator

SamuelEnglard commented Sep 27, 2016

@akoeplinger I was referencing the CLI since the DLL format is more than just CIL (of particular interest here being the binary serialization).

@MelbourneDeveloper

This comment has been minimized.

Show comment
Hide comment
@MelbourneDeveloper

MelbourneDeveloper Sep 27, 2016

Can we guarantee that anything compiled for .NET Standard will run on the .NET Core runtime environment?

MelbourneDeveloper commented Sep 27, 2016

Can we guarantee that anything compiled for .NET Standard will run on the .NET Core runtime environment?

@SamuelEnglard

This comment has been minimized.

Show comment
Hide comment
@SamuelEnglard
Collaborator

SamuelEnglard commented Sep 27, 2016

@MelbourneDeveloper

This comment has been minimized.

Show comment
Hide comment
@MelbourneDeveloper

MelbourneDeveloper Sep 27, 2016

I like those odds.

MelbourneDeveloper commented Sep 27, 2016

I like those odds.

@danmosemsft

This comment has been minimized.

Show comment
Hide comment
@danmosemsft

danmosemsft Mar 1, 2017

Member

I think this is resolved. Please reactivate if not.

Member

danmosemsft commented Mar 1, 2017

I think this is resolved. Please reactivate if not.

@danmosemsft danmosemsft closed this Mar 1, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment