Five Surprises after using .NET Core for six months

I’ve been working on .NET Core for the last 6 months; from .NET Core 1.0.1 and .NET Core 1.0.0 SDK – Preview 2 (build 003131) to .NET Core 1.1.1 and .NET Core 1.0.1 SDK.

Here’s a short list of things that surprised me:

What the hell is up with the versioning?  Read my above sentence, and pay attention to the version numbers.  If you think they’re related to one another, you’re wrong. (At least, I think you are. I’m not sure if I’m wrong or not).  Lest you think that I’m weird; this has been brought up as a common issue on .NET Core’s Github page. (I got tired of posting links; there are many, many more).  In fact, here’s a handy chart of the versioning as it existed until recently (and remember “LTS” means “Long Term Support”, which for some strange reason appears right next to the phrase “Outdated”. Screen Shot 2017-05-02 at 8.53.37 AM

They did a good job in the above chart (they were smart to take out SDK version numbers); but they included version numbers in the actual release notes, and I’m not sure which way is up:

Screen Shot 2017-05-02 at 8.58.29 AM.png

Are you using .NET Runtime 1.1.1? If so, should you use SDK 1.0.1 or SDK 1.0.3? Remember, you can use .NET Runtime 1.0.4 with SDK 1.0.3 too.

No, those version numbers are not in sync, and good luck with figuring out which SDK tooling is supported on Visual Studio for Mac, VS Code, or Visual Studio itself (Hint, anything past SDK build 3177 is probably not supported on VS 2015).

Unit Tests don’t work. Or They do work, until they don’t. Our team started out with XUnit, and then found out that XUnit wasn’t supported with all versions of .NET Core; and it wasn’t well supported on ReSharper with certain versions of the SDK Tooling; so we switched to NUnit, only to find out that now that we want to upgrade to RTM SDK Tooling, NUnit doesn’t work.  In short, the test runner that worked before doesn’t work now, and the one that didn’t work before mostly works now (unless you want to debug in Visual Studio).

Oh, and MS Test probably always worked.  (Except it didn’t).

There is a graveyard of OBE blog posts on .NET Core SDK Tooling bugs.  Depending on which version of the .NET Core tooling you’re using depends upon which answer on the internet is useful for you.  So much so that old blog posts (from 2016, mind you) are already out of date and won’t help you with your problem, even though they’re atop Google’s results.  They’ve been Overcome By Events. In this case, Microsoft.  What happened?  Microsoft decided to retain backwards compatibility (I think) with MSBuild, so project.json was jettisoned in favor of .csproj.

Versioning problems even come into play when talking about the .NET Runtime vs. .NET Core Runtime. Quick, does .NET Core have XSL support?  It has XML support, but what about XSL?  No?  When will that be coming? .NET Standard 2.0. What’s .NET Standard 2.0 you ask? GREAT QUESTION:

Screen Shot 2017-05-02 at 9.15.02 AM

It’s not often I say this, but could the Microsoft .NET Team just adopt month/year as their versioning moniker? It’d be easier to determine if two things are supported together.

So the same release of .NET Core 1.0 works with .NET Standard 1.0-1.6; how is that possible you ask? I have no idea.  In fact, if I continue to look at this chart I may start drinking early.

Does your favorite library support .NET Core? Probably not. .NET Core support has a bunch of blockers for libraries; and it doesn’t look like they’ll all get resolved before .NET Core 2.0 is released (or is that NET Standard 2.0?) It’s both this time! (But that’s happenstance). And the porting to .NET Core?  It’s most likely a rewrite before .NET Core 2.0, I still think they need to be more explicit in Step 5:

Screen Shot 2017-05-02 at 9.21.17 AM.png


Over all, I’m glad that I’ve gotten to work on .NET Core; but given that I’ve spent a non-trivial amount of time over the past 6 months wrestling with these issues; I’m not even certain what performance issues will crop up from running .NET Core on Linux (Docker).  That’ll be for a future blog post, I’m sure.