.NET Core, a call to action


It’s time to port your packages to .NET Core and the .NET Platform Standard: go go go.

.NET Core, yay

Yesterday we finally got our hands on the first Release Candidate of .NET Core, which I sincerely hope is the future of the .NET platform and ecosystem. We, the consumers, should be able to choose to run our applications and services on Linux or Windows Server 2016 Nano Server, and in Docker containers on orchestrated, scheduled clusters. .NET Core is the first—huge—step on the road to that kind of choice. Congratulations to all the teams who have been working on the Core CLR, Framework, Runtime and Tooling, as well as ASP.NET Core and Entity Framework Core. (If I’ve missed anyone there, then sorry: congratulations to you too.)


The next wave of work must be undertaken by the wider .NET community, both inside and outside Microsoft.

Building a modern .NET application relies on a vast array of first- and third-party packages, mostly open source and on NuGet. Visit the GitHub projects for some OSS .NET projects and you’ll see an issue for "Support .NET Core"; visit others, and you’ll see no mention at all.

I’m hoping that OSS project maintainers will trust that what we have now in RC2 is going to remain stable in API terms, even if the metadata side of things is likely to remain in flux a little longer, and start the work to make the transition.

(I made a start on Simple.Data Core last night, although I haven’t pushed it to GitHub yet.)

Unfortunately, the nature of a package-based ecosystem such as NuGet can mean that Project Z can’t be updated until Project Y releases .NET Core packages, and Project Y may be waiting on Project X, and so on.

An example

(I’m not calling these projects out to be mean; they’re just a good example.)

The Azure Storage SDK for .NET (known on NuGet as Microsoft.WindowsAzure.Storage) released a version for DNX and CoreCLR, but that version was based on the cut-down WinRT library. The full-fat library ("Desktop") uses HttpWebRequest extensively, which was obsoleted in CoreFx, and a rewrite to HttpClient was not something the team were willing to commit to.

Since that discussion, a System.Net.Requests package has been added to CoreFX, providing what is essentially a WebRequest-shaped shim around HttpClient, so porting the Storage SDK should be much easier now.

The outstanding issue is that Microsoft.WindowsAzure.Storage depends on Microsoft.Azure.KeyVault, and most of the OData packages.

Microsoft.Azure.KeyVault is part of the Azure SDK for .NET project, which has "CoreCLR Updates for RC2" as an issue for their May sprint milestone, so we may hope that will be available soon.

The OData project repo has no mention of .NET Core anywhere (at least, it didn’t until I opened an issue). There are no project.json files in the repository, no mention of the new .NET Platform Standard target framework monikers.

In an issue from a year ago, one of the team said:

It is the basic building block of many OData products.

And he’s right; it is.

But today, trying to install the Microsoft.Data.OData package into a .NET Core RC2 project results in this:

Errors in C:UsersmarkCoreConsoleApp1srcConsoleApp1ConsoleApp1.xproj
    Package System.Spatial 5.7.0 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package System.Spatial 5.7.0 supports:
      - net40 (.NETFramework,Version=v4.0)
      - portable-net40+sl5+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile328)
      - portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
      - sl4 (Silverlight,Version=v4.0)
    Package Microsoft.Data.OData 5.7.0 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package Microsoft.Data.OData 5.7.0 supports:
      - net40 (.NETFramework,Version=v4.0)
      - portable-net40+sl5+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile328)
      - portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
      - sl4 (Silverlight,Version=v4.0)
    Package Microsoft.Data.Edm 5.7.0 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package Microsoft.Data.Edm 5.7.0 supports:
      - net40 (.NETFramework,Version=v4.0)
      - portable-net40+sl5+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile328)
      - portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
      - sl4 (Silverlight,Version=v4.0)
    One or more packages are incompatible with .NETCoreApp,Version=v1.0.

OK, so RC2 only came out yesterday, not everything can happen at once (although most of the work could have been done by now using the RC2 nightly builds). At the very least, though, there should be an issue acknowledging that the work needs to be done, even more preferably with a milestone, preferably with a date attached to it.

The OData team have been extremely good at supporting the .NET Portable Class Library specifications. Now they need to be equally good at supporting the new .NET Platform Standard.

Microsoft-run projects especially need to lead by example at this point, and that means aggressively adopting and supporting these new technologies and standards. After the trials and tribulations of the last few months, if people see Microsoft teams holding off migrating to Core, they’re going to wonder if those teams know something we don’t.

And if even those who are ready to make the leap are blocked by an upstream dependency, particularly on a Microsoft-maintained package, then we’re going to be stalled here for a while. After all the waiting we’ve already endured, that would be a tragedy.

Share on facebook
Share on google
Share on twitter
Share on linkedin


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.