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”. 
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:
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:
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:
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.
George,
.Net Standard can be confusing until you realize that .Net Standard isn’t a platform itself. It’s just a set of common APIs across the platforms. That’s why .Net Core (the platform) supports .Net Standard libraries 1.0-1.6; it has implementations of the APIs that .Net Standard specifies. .Net Standard 1.0 libraries have the fewest available APIs, because they can be used on the most platforms and those platforms taken together have the fewest APIs in common. Likewise, .Net Standard 1.6 libraries are supported on the fewest platforms, because it specifies the largest set of APIs and very few platforms have implemented all of them.
I’ll create a fake example to illustrate, referring to the famous .Net Standard version chart you have above. Let’s pretend that Object.ToString() has been implemented on the .Net Core platform, but not on Windows Phone Silverlight. That means that API would not be available for use in a .Net Standard 1.0 library, because not all of the supported platforms have implemented Object.ToString(), in this example. However, if it was implemented in every other platform except Windows Phone Silverlight, then you can expect to be able to target .Net Standard 1.1 (which includes support for all those other platforms) in order to use that API.
.Net Standard 2.0 will specify even more APIs than are available in 1.6, which is why it is supported on fewer platforms still. The reason .Net Core and the new .Net Standard 2.0 API set are being released pretty much simultaneously is that they are more or less defining what APIs .Net Standard 2.0 contains as what will be implemented and available on the .Net Core 2.0 platform.
Additionally, because .Net Standard is just a definition of available APIs, that’s why you can’t create a .Net Standard executable. It doesn’t make sense. You need some platform to run on. Platforms can _consume_ .Net Standard compatible libraries, but .Net Standard is not a platform you run things on, unlike Core, Framework, or Mono.
I hope that explanation helps a bit. As an aside, I’ve also found that the testing story for .Net Core is a bit messy at the moment. However, xUnit does seem to be out ahead currently. NUnit is scrambling to update to the new csproj tooling though, and then it will work again.
-Matt
This clears some things up for me, thanks!
George,
.Net Standard can be confusing until you realize that .Net Standard isn’t a platform itself. It’s just a set of common APIs across the platforms. That’s why .Net Core (the platform) supports .Net Standard libraries 1.0-1.6; it has implementations of the APIs that .Net Standard specifies. .Net Standard 1.0 libraries have the fewest available APIs, because they can be used on the most platforms and those platforms taken together have the fewest APIs in common. Likewise, .Net Standard 1.6 libraries are supported on the fewest platforms, because it specifies the largest set of APIs and very few platforms have implemented all of them.
I’ll create a fake example to illustrate, referring to the famous .Net Standard version chart you have above. Let’s pretend that Object.ToString() has been implemented on the .Net Core platform, but not on Windows Phone Silverlight. That means that API would not be available for use in a .Net Standard 1.0 library, because not all of the supported platforms have implemented Object.ToString(), in this example. However, if it was implemented in every other platform except Windows Phone Silverlight, then you can expect to be able to target .Net Standard 1.1 (which includes support for all those other platforms) in order to use that API.
.Net Standard 2.0 will specify even more APIs than are available in 1.6, which is why it is supported on fewer platforms still. The reason .Net Core and the new .Net Standard 2.0 API set are being released pretty much simultaneously is that they are more or less defining what APIs .Net Standard 2.0 contains as what will be implemented and available on the .Net Core 2.0 platform.
Additionally, because .Net Standard is just a definition of available APIs, that’s why you can’t create a .Net Standard executable. It doesn’t make sense. You need some platform to run on. Platforms can _consume_ .Net Standard compatible libraries, but .Net Standard is not a platform you run things on, unlike Core, Framework, or Mono.
I hope that explanation helps a bit. As an aside, I’ve also found that the testing story for .Net Core is a bit messy at the moment. However, xUnit does seem to be out ahead currently. NUnit is scrambling to update to the new csproj tooling though, and then it will work again.
-Matt
Well I agree, no matter which way you look at it the versioning of all this is a total disaster! Testing-wise maybe I’ve been lucky but I’ve been using xUnit since RC builds and never had any problems, in and out of VS. I do remember having to mess around at the start to find the right runner but haven’t had a problem since.
The point about search results is something companies need to think about a lot more. Angular now has the same issue and it’s a much bigger problem than for dotnet core.
Having said all this, I think there are plenty of positives to dotnet core as well, it’s no small thing what they’ve done and the team would have gotten a better response if they’d simply kept things in beta longer.
Just had to amend my jenkins job for a dotnet core project and see the runner I was talking about above is currently dotnet test, and I left a comment saying the xunit runner no longer works so seems I did go through a similar pain as you a while ago! So I am still using xUnit in VS and I’m using xUnit tests using dotnet test as the runner outside of VS:
dotnet test my_test_project.csproj –configuration Release –logger “trx;LogFileName=test_results\my_test_project_results.xml”
George, I totally agree about the versioning. Confuses me to no end and trying to explain to users exactly what they need to install to build our project is a pain.
For NUnit tests, I released an alpha release of the test adapter last night, https://www.nuget.org/packages/NUnit3TestAdapter/3.8.0-alpha1. Hopefully it will help solve your unit testing problems 🙂 I will be writing a blog post to outline how to use it this afternoon, but until then the release notes should get people started, https://github.com/nunit/nunit3-vs-adapter/releases/tag/3.8-alpha1
Hello, really nice article, i would like to add that if You would like to use IPC in .Net Core, there is only client side of WCF, and they decided to not port .Net Remoting, so simply there is no high level IPC at all only named pipes and memory mapie files. I am trying to use ZeroMQ to make IPC between two processes on the same machine in .Net Core to have at least something instead raw pipe. Interesting thing is that Mono is supporting .Net Remoting and they are saying that they will copy WCF from .Net Core asap Microsoft will release it, but Mono is dying right now, i think all Xamarin is working on .Net Core. So if You want IPC You can only use low level stuff, like in c++, so what is a point of using .net?
I think you’ve misinterpreted their intention with Step 5. Clearly they mean you should take your porting plan out back and pump a few shotgun shells into the back of it’s head.
As far as testing goes; Expecto supports the latest .Net Core: https://github.com/haf/expecto#net-core-support – and since it’s a command line tool, you can use it if you can run an executable.
Hope most of the concern is addressed in latest .net core version. specially compatibility issues