Runtime: .NET Core + Existing Platforms - What Can We Expect?

[shiftkey]

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?

[clairernovotny]

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]

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]

@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]

@n8ohu I can't answer that. :)

[clairernovotny]

@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]

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]

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]

@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]

@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]

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]

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

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]

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

[dsplaisted]

@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]

@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]

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

@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]

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

[RichiCoder1]

@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]

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]

@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]

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]

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]

@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]

@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]

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

[am11]

@davkean, thanks! :+1:

[cdrnet]

@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 may be relevant: Understanding .NET 2015 (posted today)

[am11]

@cdrnet, thanks for the blog link! :+1:

BTW this extract linked in @bethmassi's post is very useful (ASP.NET Overview – What about Web Forms?):

To see if your application can run on the cloud-optimized runtime, use the API Portability Analyzer. This tool tells you which platforms your application can target and which dependencies prevent your application from running on other platforms. It helps you understand the scope of required changes and suggests new types or members to use in place of unsupported ones.

[adamralph]

@cdrnet thanks, that definitely does help.

@davkean that blog post contains something similar to what I had in mind. Did you have a part in getting that out there? :wink:

It's a good step towards getting a canonical reference, but it's still not quite there yet. E.g. The diagram in the blog post has the positions of core CLR and .NET native with respect to .net core reversed. Consider

in comparison with

(The language used by @davkean matches the former, i.e. .net core running 'on top of' core CLR and .NET native for the respective app models, which seems to make sense.)

The latter doesn't contain the 'runtime adaption layer' and each diagram conveys a different meaning for '.net core'.

Sorry, I know that sounds like nitpicking but there is a large community throwing around these names liberally so in the absence of canonical meaning it's easy to get lost in conversations.

Anyway, I certainly know a lot more now than before I entered this conversation, and I'll be keeping the link to that post handy!

I do have some specific questions with regard to the latter diagram

• Does it indeed capture the entire .net platform or is there anything missing? (I'm not referring to detail within the boxes, but anything outside them.)
• The 'common' layer seems to be implying that all those components will be able to run on every platform. Is that correct? I.e. do we get RyuJIT, SIMD and Roslyn, running on all of Windows, Windows Phone, Linux and Mac?
• Where, if anywhere, do iOS and Android fit on the diagram? Or is that still in a separate Xamarin domain? If so, what is Xamarin's entry point into the stack and what is supported there?

[adamralph]

Oh, and there is in fact a re-worked version of the former diagram lower down in the post :smile:.

[BethMassi]

@adamralph Very good points! @terrajobst and I went back and forth a couple times with the first diagram. I agree putting the runtimes "on top" of the core is a little weird, but it was necessary to convey that the UAP app model has a different runtime.

[adamralph]

@BethMassi it's a good post and definitely a big step forward in clarifying things.

I can understand the dilemma you had, I'd suffer the same if preparing that diagram. Whilst they are lower level concerns, the core CLR and .NET Native are each serving the higher level concerns of ASP.NET 5 and Universal, and each pair straddles .NET core (aka Unified BCL). However, in the end I think I would have plumped for putting them below as it does allow the opportunity for the runtime adaptation layer to assume it's natural place too. That is, as long as the connection between ASP.NET 5+Core CLR and Universal+.NET native can still be made clear.

I just realised that one of my questions above contains an obvious nonsense - RyuJIT on Windows Phone - that obviously doesn't apply since .NET Native is ahead of time compilation. So I guess RyuJIT (and SIMD?) does indeed apply to all boxes apart from .NET Native and Universal.

I'm still wondering where Roslyn will be able to run? That's of particular interest to me as a core team member of https://github.com/scriptcs/scriptcs :wink:

[adamralph]

BTW, I understand that Roslyn will be filling the compilation part of the pipeline for getting from source to runtime for all of what is shown, but in my question I'm referring to runtime platform support for Roslyn itself, i.e. on which platforms will I able to invoke Roslyn to compile C# - hence my interest regarding scriptcs, since one of the aims of the project is to add scripting capabilities to apps at runtime, which could potentially be running on any device.

[am11]

@adamralph, apparently Roslyn team is considering cross-platforms as well. See: https://github.com/dotnet/roslyn/issues/312.

[davkean]

Going from C# -> IL will not work in places that do AOT (Ahead-of-time compilation) (.NET Native/Xamarin iOS) because they do not have a JIT. You'll need to either pre-generate the IL during build, or interpret (which is what System.Linq.Expressions will be doing).

[jaredpar]

@adamralph

The intent is that Roslyn will be able to target coreclr and hence run wherever it does. That work that is on going at the moment and hopefully should start making strides next week.

The work hopefully won't even be that disruptive. A large portion of the code base already targets the Portable Class Libraries and hence needs no altering. There are just a few packages which currently target desktop CLR that need to move to target coreclr instead.

The current source of Roslyn can also run on top of mono. I've actually built Roslyn with Roslyn using mono on my MacBook. I had to make a minor fix to the code to work around a mono issue but other than that csc.exe runs unaltered. This isn't officially supported at the moment but it does work (and is just fun to play with).

Does that help answer the question?

[adamralph]

@davkean that makes sense, thanks.

@jaredpar yes, that does help, thanks. When you say

There are just a few packages which currently target desktop CLR that need to move to target coreclr instead.

What do you mean by 'move'? Is it that they need to target PCL instead, with a profile spanning desktop CLR and Core CLR?

[jaredpar]

@adamralph

They cannot target the same PCL as the rest of Roslyn because it lacks APIs that we need in order to compile: in particular access to the file system. Instead they need to target CoreCLR which has the appropriate portable APIs.

[adamralph]

I see, so anything which targets CoreCLR will also be able to run on the desktop CLR?

[davkean]

I want to clarify something here. Roslyn isn't going to target "CoreCLR", per se, they are targeting ".NET Core", if you target ".NET Core", you will be able to run on the full CLR.

[jaredpar]

@davkean has the right of it.

[adamralph]

Ah OK, so those remaining packages will switch to targeting ".NET Core", and anything which targets ".NET Core" can still run on the ".NET Framework"?

[davkean]

Effectively yes. There'll be a PLIB experience that lets limit yourselves to APIs that run on older versions of .NET Framework, but for the initial release, .NET Framework 4.6 will be a superset of the APIs in ".NET Core".

".NET Core" (similar to Phone 8.1/Windows 8.1), by construction, has a portable surface area.

[gulbanana]

This discussion has been very helpful, but there's still one thing I don't understand:
You've mentioned that due to the nature of .NET core it isn't a new 'target' in the sense of being a new set of fixed reference assemblies. What about this scenario:

Portable Class library MyLib references System.IO.File and contains MyCoolType
Desktop application WinApp targets net45
ASP.NET 5 application targets aspnetcore50

Both of those targets have System.IO.File available, either built in to the old framework or via package System.IO.FileSystem. So it should be ok to use it in MyLib. But... how? The existing portable profiles all exclude System.IO.File, as they all include either win8 or winphone8 or _something_ without it. Wouldn't we need at least one new PCL profile here?

[dsplaisted]

@gulbanana Once we have the tooling for Portable Class Libraries working, you should be able to select .NET 4.6 and ASP.NET Core 5.0 in the portable targets dialog, and then you would be able to use System.IO.File.

We don't plan on adding new PCL profiles for this, as having a separate PCL profile for each possible combination of platforms doesn't scale. So when you are targeting only newer platforms (such as .NET 4.6, Universal apps, and ASP.NET Core 5.0), you wouldn't end up targeting a PCL profile. But this should be pretty transparent and the experience should basically be the same (or better).

[gulbanana]

Alright, that sounds like a viable way to go. Will it be possible to target an older platform like .NET 4.5, and also a newer one like ASP.NET Core 5.0, using a library that targets both the old style fixed profile and a new style portable target?

[davkean]

Yes. Anything that supports "System.Runtime" portable (.NET 4.5+, Win8+, Phone8+, Xamarin Android/iOS) will be able to be combined with .NET Core.

[gulbanana]

Great, that means we won't lose any flexibility at all. Thanks for the clarification.

[adamralph]

@davkean OK, that certainly clarifies things, thanks!

So my remaining questions regarding the latter diagram are:

• Does it indeed capture the entire .net platform or is there anything missing? (I'm not referring to detail within the boxes, but anything outside them.)
• Where, if anywhere, do iOS and Android fit on the diagram? Or is that a separate domain owned by Xamarin? If so, what is Xamarin's entry point into the stack (either current or planned/envisaged)? Or are there no firm plans in that area? I.e. for now they will continue to sit on top of Mono (which obviously sits outside the diagram) or their own forks of these components?

[xanather]

Last I heard Xamarin is pulling in a lot of the code found on CoreCLR/CoreFX for their platforms. I doubt Microsoft is going to officially support them with CoreCLR.

[clairernovotny]

@davkean

Yes. Anything that supports "System.Runtime" portable (.NET 4.5+, Win8+, Phone8+, Xamarin Android/iOS) will be able to be combined with .NET Core.

So this is still the source of my confusion. If I'm ok with supporting only those platforms, can we use the new System.IO.File for example? Or is it saying that .NET Core will run those "older"/"wider" libraries?

[Mike-E-angelo]

I am also incredibly interested in Xamarin's integration with .NET Core and Windows 10 ecosystem, so add me to that list, where ever it is.

I doubt Microsoft is going to officially support them with CoreCLR.

Welllllll technically speaking, they are. According to this picture, that is (denoted by "Any other app model"):

Of course, I could have this wrong (very possible). There are a lot of moving pieces here and I don't think any one of us is really going to have an appreciation/understanding for it all until we have VS2015 Beta 1 running on machines to check it all out, which should be around April 29th I am guessing. :)

(Btw, this is an incredibly informative thread. Thank you all for all the of the information. I am about 15% confused now after being about 90% confused around this initially, FWIW. :+1:)

[clairernovotny]

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]

:+1: @onovotny!

[adamralph]

@onovotny thanks, that definitely helps!

[ghost]

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

[MelbourneDeveloper]

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?

[clairernovotny]

@MelbourneDeveloper Would cross-compiling make this easier?

[Mike-E-angelo]

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]

@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-E-angelo]

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]

@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]

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]

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-E-angelo]

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]

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

[MelbourneDeveloper]

@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]

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]

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

[SamuelEnglard]

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

[MelbourneDeveloper]

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

[SamuelEnglard]

@MelbourneDeveloper 99%

[MelbourneDeveloper]

I like those odds.

[danmosemsft]

I think this is resolved. Please reactivate if not.