.NET Core 2 is great, most of the API is back, project references are seamless, and VS2017 is fast, lightweight and nice to use (even without resharper). A lot of 3rd party libraries are waiting on this too so there should be a lot more momentum this year.
It pretty much resembles the way .NET Framework also changed drastically from 1.0 to 2.0 which finally became the productive and trusted framework of today.
It's also really nice to be able to see all of this happening out in the open with the actual developers and leaders at Microsoft. They don't always make the right/best decision but at least they explain what they did and they're definitely taking feedback. It's very refreshing from the old .NET days where everything was opaque until the new release notes came out.
Its really great, but some of the APIs could have been re-designed slightly when they "rebooted" the framework... e.g. getting rid of factory patterns when strictly not needed and such for added consistency.
Can I see an example? I get shifty when I see people saying things like 'factory pattern not strictly needed'. For example, there are moments where an API may need you to construct an object with a certain set of 'default properties'. I believe that rather than making developers generate 'boilerplate' there should just be some kind of 'boilerplate' factory.
So, these boilerplate factories are not strictly necessary but they make the API user's code simpler, more comprehensible, isolate responsibilities, etc.
Read the .net framework standard library annotated reference for some commentary by the original framework devs to understand what they would have changed.
My experience with Telerik has been similar, although not as bad as yours I guess, plus it was long ago. However, this article seems to be mostly about .NET Core and Telerik-independent.
I've finally got to the stage where none of my projects contain 3rd party dependencies that aren't open source. It has removed a whole load of aggravation and expense.
My issue with Telerik was more to do with their free tools. The installer tries everything to install trials of everything, and the free tools dial home every time you start them and try to encourage you to log in to a Telerik account or upgrade. At one point they were using a port/protocol blocked by our corporate firewall to download the "what's new/updates are available" content and Just Decompile would literally crash every time it started up unless I disabled all of my network cards/wifi. But not immediately, it would fully start and it would be like 10 - 15 seconds later that it bombed. Not the greatest. It's a shame, because the actual free products are very good once you get past those annoying shortcomings.
I wonder if there is some confusion between .NET Standard and .NET Core. As .NET Standard 2.0 is a thing but I can't find any official reference to .NET Core 2 yet. Obvious, this will eventually come but it's not on the roadmap yet as far as I can see.
Disclaimer: I've not been paying as close attention as I did last year when writing my book on .NET Core (https://unop.uk/book/). So I may just have missed something.
Milestone Release Date
.NET Core 2.0 Spring 2017
.NET Standard 2.0 Spring 2017
This is weird as I had previously heard this would be v1.2. Perhaps it is but it's now a major bump rather than a minor one. Either a breaking change or to tie in with .NET Standard?
I guess this means it won't stay aligned with the ASP.NET Core versions now?
I spend time writing a helpful comment and the thread gets flagged. :(
>Either a breaking change or to tie in with .NET Standard?
Maybe they just want to sync with .NET core tools which have a breaking change even if they are currently RC - just moving everything to 2.0 would signal that everything is in sync now - hopefully.
They need a major version re-release, 1.0 was premature for the way it was done, hoping they get things right with 2.0
From the roadmap: "Because of this, if you follow our repositories you will start to see .NET Core 2.0 versioning."[0]
As an aside, I find it helpful to think of .net standard as an interface (API definition, no code), and .net core as a class (implements interface, provides implementation, possibly additional methods).
public class NetCore2_0 : INetStandard2_0 {}
public class NetCore1_0 : INetStandard1_6 {}
.NET Core 1.2 is now 2.0 so that it aligns with .NET Standard and reduces confusion (of which there is too much already and the worst part of .NET in general).
.NET Core Whatever Wave - it won't work as advertised. The team don't even have an established release process. This whole situation is like OS/2 and IBM if you know what I mean.
I really want to use it as I much prefer Linux as a hosting platform over Windows, but I really enjoy C# and F#. When I last looked, however, the tooling just wasn't there. I found documentation still referencing the outdated dnx command as opposed to dotnet, and building something as simple as a console application required quite a bit of boilerplate project.json. I haven't looked at it since, but I hope the move back to csproj will simplify things a bit. I'd really like to see the dev experience ironed out a bit more as it's quite an exciting project.
I just looked up what exactly .NET Core is and landed on the installation guide page[1], which includes installation videos for Windows and Mac OS.
It's quite funny how they, uhm, adapted those to target audiences... :)
In the Linux tab of the instructions there are tabs for various Linux distributions (each with slightly different instructions). The instructions for Ubuntu are the only ones with a video.
Kendra Havens is a hilariously funny in those videos. She does a really good job of making setting everything up seem like a whole load of fun rather than a chore.
"Preview 2" is the tooling version (command line tools). The tools (such as the dotnet command and related binaries) are versioned separately from the framework itself.
This allows the team the ability to release new tooling versions (bugfix to the donet command for example), without having to print a new framework version. Same for updating the framework vs the tooling.
On the one hand, it's annoying to keep track of so many versions. On the other hand, it's also annoying to be forced to run a framework update when the only thing that's changed is a command line tool, which may or may not be important to a specific organizations development pipeline.
DirectX isn't exactly as much fun as a barrel of monkeys, but it's less painful and crufted up with less legacy junk than OpenGL. I can see why approximately no one writes games for Linux and Mac if they aren't already using a cross-platform engine that's done that heavy lifting already.
34 comments
[ 3.2 ms ] story [ 80.4 ms ] threadIt pretty much resembles the way .NET Framework also changed drastically from 1.0 to 2.0 which finally became the productive and trusted framework of today.
It's also really nice to be able to see all of this happening out in the open with the actual developers and leaders at Microsoft. They don't always make the right/best decision but at least they explain what they did and they're definitely taking feedback. It's very refreshing from the old .NET days where everything was opaque until the new release notes came out.
So, these boilerplate factories are not strictly necessary but they make the API user's code simpler, more comprehensible, isolate responsibilities, etc.
I've had nightmares with their stuff. Their standard response to any problems you might have with their controls is "wait for the next version"
That was pretty funny.
https://github.com/aspnet/home/wiki/roadmap
https://blogs.msdn.microsoft.com/dotnet/2016/07/15/net-core-...
Disclaimer: I've not been paying as close attention as I did last year when writing my book on .NET Core (https://unop.uk/book/). So I may just have missed something.
Edit:
I've found some more info: https://github.com/dotnet/core/blob/master/roadmap.md#ship-d...
This is weird as I had previously heard this would be v1.2. Perhaps it is but it's now a major bump rather than a minor one. Either a breaking change or to tie in with .NET Standard?I guess this means it won't stay aligned with the ASP.NET Core versions now?
I spend time writing a helpful comment and the thread gets flagged. :(
Maybe they just want to sync with .NET core tools which have a breaking change even if they are currently RC - just moving everything to 2.0 would signal that everything is in sync now - hopefully.
They need a major version re-release, 1.0 was premature for the way it was done, hoping they get things right with 2.0
As an aside, I find it helpful to think of .net standard as an interface (API definition, no code), and .net core as a class (implements interface, provides implementation, possibly additional methods).
[0] - https://github.com/dotnet/core/blob/master/roadmap.mdNo doubt they my become unaligned again in the future; but I think its about starting from a clean version number alignment.
e.g. .NET Standard 2.0 was originally .NET Standard 1.7 which would have gone with .NET Core 1.2 with tooling (CLI) 1.0
This is a good reference: https://docs.microsoft.com/en-us/dotnet/articles/standard/li...
Just replace .NET Core vNext with 2.0 and you're looking at the latest mapping of .NET Standard implementations.
I don't think it's ready for prime time yet. Gonna give it at least another year.
[1]: www.microsoft.com/net/core
The version labeled 1.0.3 TLS is dotnet-dev-osx-x64.1.0.0-preview2-003156.pkg (1.0.0? preview?)
The version labeled 1.1 is dotnet-dev-osx-x64.1.0.0-preview2-1-003177.pkg (again: 1.0.0 preview?)
The linux packages have similar pattern.
So, 1.0.0-previewX < 1.0.0.
Semantically this should be read as "1.0.0-previewX is preview X of version 1.0.0"
This allows the team the ability to release new tooling versions (bugfix to the donet command for example), without having to print a new framework version. Same for updating the framework vs the tooling.
On the one hand, it's annoying to keep track of so many versions. On the other hand, it's also annoying to be forced to run a framework update when the only thing that's changed is a command line tool, which may or may not be important to a specific organizations development pipeline.
It's just the kind of thing that we all* walk around armchair quarterbacking the fact that Microsoft would never do that in a million years...
Seriously.. how cool would that be?
*of course I mean "all" colloquially - obvioulsy there are some people who don't say that.