Why We Cannot Yet Support .NET Core

Microsoft has announced a number of “alternative” .NET runtime implementations in the last few years, including .NET Core, .NET Native, the Dynamic Language Runtime (DLR), and the Brokered Windows Runtime, most of which have been open-sourced. Current attention is primarily on .NET Core, a pared-down version of .NET designed to run on multiple platforms, including Windows, Linux, FreeBSD, and Mac OS X. We’ve been watching the development of .NET Core, and recently took a deeper look to see if it’s ready to use with JNBridgePro. The answer is “Not yet.” It appears that in the determination of which .NET APIs are “Core,” the definition of what defines “Core” has been drawn too narrowly.

The documentation for .NET Core is far from complete, but there are tools that help developers analyze both source code and compiled binaries to determine whether they access unsupported APIs. You can download the tool here — use the command-line version, which seems more solid than the Visual Studio plug-in. When we ran the tool on our binaries (and you too can run it on any binaries you choose, yours or ours), we see unsupported calls in the following APIs, and more:

  • Windows Forms
  • AppDomains
  • Crypto library
  • SSL streams
  • .NET remoting
  • Threading
  • Time zone handling
  • Processes
  • Transactions
  • Emit
  • Custom serialization
  • Event logging
  • TcpClient and TcpListener
  • Registry access
  • config APIs
  • WriteLine

We can speculate as to why these APIs are missing. Some of these, like threading, processes, SSL streams, the crypto library, and event logging, may be things that the developers just haven’t gotten around to implementing yet. Others, like AppDomains, custom serialization, and Reflection.Emit, may be considered esoteric and a low priority, or simply too difficult to implement. Still others, like Windows Forms, .NET remoting, and registry access, are legacy APIs that the .NET Core developers might be trying to steer developers away from — or maybe they haven’t yet gotten around to them. But the specific reasons don’t matter, and regardless of reasons, it doesn’t yet seem that .NET Core is ready to run serious enterprise applications, as any substantial application will use many of the above APIs. Whether it will ever be ready remains to be seen.  We will track developments in NET Core, and run the analysis tool periodically to see whether the list of supported .NET APIs continues to grow.

Do you have plans to use .NET Core? Let us know.