November 8, 2016

TL;DL – .NET Rocks! 1371 (.NET Standard with Immo Landwerth)

Show link: .NET Rocks! 1371: .NET Standard with Immo Landwerth

Guest: Immo Landwerth

Show Notes

  • Portable Class Libraries (PCLs) give you the lowest common denominator of APIs that can run on a variety of platforms. .NET Standard states what APIs will be supported for a particular version.
    • It’s technically not the lowest common denominator, as it depends on which overlapping technologies you want to support. You want the platforms to buy into the portability mechanism.
    • With .NET Standard, you target something like a platform with a version number; the higher the version number, the more APIs you can use. It’s up to the platforms to implement up to that standard.
  • If you have a version of .NET Standard and there’s an update, do you just do those minor revisions?
    • .NET Standard follows semantic versioning, where you increment the minor version when APIs are added.
    • .NET Standard v2.0 will not have breaking changes (as is usually the case for a major version number change), but the change will be significant enough to warrant the major version increment.
  • How has the adoption of .NET Standard been?
    • This was done at the same time as .NET Core, where all of the stack became open-source. There has been incredible community engagement, especially with those Microsoft didn’t interact with before.
    • The biggest problem was that .NET Core was new and was a small subset of .NET, so there weren’t many shared APIs, therefore .NET Standard v1.0 wasn’t that big, which meant porting to .NET Core or Standard was hard.
    • Microsoft actively tracks the number of NuGet downloads for .NET Standard; as of late 2016 the number of .NET Standard-based packages is equal to number of PCL-based packages.
  • Are there any internal projects at Microsoft using .NET Standard?
    • Yes; there are many client-side libraries to access Office, Visual Studio, Bing, and Azure. We want to support .NET Framework and .NET Core without maintaining two codebases.
  • Xamarin works with shared projects and PCLs. Will we see a .NET Standard option?
    • Yes. You have two options: (1) share source code and compile it for each platform, and (2) use PCLs and .NET Standard where a single binary is loaded and executed.
    • Pro for sharing:  more flexibility with #if statements to call the appropriate APIs.
    • Con for sharing: you don’t know which platforms to write for if you’re a library vendor, so you’re always playing catch-up.
    • Pro for PCL: you don’t need to know what platform you’re targeting.
    • There are richer APIs in the .NET Standard than with PCLs.
  • Everyone’s hanging on for .NET Standard v2.0 (.NET Core and Xamarin and Universal Windows Platform (UWP)).
    • This situation is similar to when .NET v2.0 came out with support for things like generics, which helped the framework take off.
  • Is anyone else going to want to comply?
    • Microsoft had an active outreach with Unity and Xamarin to get an ecosystem for the libraries. We all need to integrate to make our lives easier and our customers’ lives easier — we both benefit.
    • .NET Standard is a contract for both sides: Providers know what APIs to support, and library authors know what APIs they should limit themselves to so they can run everywhere.
    • If you want .NET developers to build on your platform, get to .NET Standard.
    • .NET Standard is in the spirit of the ECMA specifications, but instead of focusing on the runtime, it focuses on the API.
  • What platforms support .NET Standard today?
    • .NET Core, .NET Framework, Mono, Xamarin (fork of Mono customized for iOS and Android), UWP, Windows, Windows Phone, Windows Phone Silverlight. Unity is coming soon.
  • You may not think of Unity as it’s own platform.
    • Many developers are using .NET as the runtime for the game. It’s like middleware: You don’t care what it’s written in. .NET makes it easy to extend, has good support for tools, etc.
  • Is .NET Standard one platform to rule them all?
    • Not really. .NET Standard is the bottom piece (i.e., set of APIs). There is still a need for the specific platform APIs to exploit the power of that platform.
  • Where would you like .NET Standard to be in late 2017?
    • Hopefully released and in people’s hands, to have community NuGet packages at v2.0, and that it will be relevant (i.e., not just a blog post or a spec).
  • There’s a big jump from .NET Standard v1.6 to v2.0.
    • If you’ve tried targetting .NET Standard and were thinking of giving up, wait for v2.0.
  • What are the inclusion principles?
    • The key parts of the platform — primitives (e.g., strings, collections), run-time specific APIs like the garbage collector, and APIs you need for good libraries (e.g., classes in System.Data).
    • There’s been discussion about whether or not to include Json.NET. The problem is the dependency .NET Standard would take on revisions of that project (i.e., Json.NET can move quicker than standard can). Having it be separate means that Json.NET can update as frequently as the project needs.
    • The standard is only about APIs, not security updates. How updates are distributed depends on the platform.
    • We only want to add things that are mature/stable or are essential to the API.
  • How many APIs took a lot of arguing?
    • Everyone has strong opinions, given how long .NET has been around.
    • If you compare .NET Core with the .NET Framework, you’ll get a good idea of where it wouldn’t work.
    • The biggest discussions have involved reflection. .NET Core involves some kind of ahead-of-time compilation (i.e., no just-in-time compilation, but generate machine code during the build process). A key concern was if we do that, will we be able to support reflection, because when you do ahead-of-time compilation, you do static linking, which means you need to know that kind of APIs you need in the output binary. With reflection, you could invoke anything all the time. .NET Standard v2.0 has many other reflection APIs that .NET Core does not.
    • There are times when its simpler to keep the old APIs even if there are better types available — e.g., returning an array instead of an IEnumerable.
    • Writing maintainable reflection code is hard.
  • What does .NET Standard do about file path length limits?
  • There are some APIs that cannot be ported, for example some file APIs that depend on Windows Access Control Lists (ACLs). You can either not put them in the API, or have them throw an exception depending on the platform. If you choose to use exceptions, now the developer has to guard against them. .NET Standard has tried not to use this approach.
  • Early on there was a usability study that asked whether developers would prefer a compile-time error or a run-time exception. As long as the exception message was good, that was preferred because you can get more context. This design is difficult to test against, though.
  • With over 32,000 APIs for .NET Standard v2.0, if I’m trying to bring my platform to .NET Standard, that’s a big mountain to climb.
    • In perspective, four years ago, there was no open source, so you’d have to implement the ECMA standard yourself.
    • The codebases will get more aligned over time; then, that code could be forked if needed for a special purpose. For example, nobody re-implements Linux from scratch. One could simply start with .NET Core and tweak from there.
  • How can people contribute?
    • The work on the standards is about decisions; the dev work involves tooling.
    • People can provide feedback — Are the standards good? Are we missing some? Should some not be there?
    • There will be development needed to get .NET Core implementing the standard.
  • How do you evaluate that you comply with .NET Standard v2.0?
    • Microsoft has a test suite for API compliance — i.e., is the API in the right place and binary-compatible to what the standard says (e.g., method signatures).
    • There are no unit tests on the API behaviors, as those could vary by platform.

Better Know a Framework

Listener E-mail

From show #1349 (ASP.NET WebForms Is Alive with Jeff Fritz); concerns over upgrade path for ASP.NET core, however you can run them side by side. You can move over to WebAPI and MVC (on .NET Core) and have WebForms on the main framework.

Technology Giveaway Ideas