Dotnet Core is nice for server software, but Microsoft still didn't address the biggest pain point for desktop applications: the lack of a multi-platform UI framework. This is a pure "strategic" decision, as Silverlight was released for OSX as well as Windows. Instead, they persisted on their UWP platform which didn't even run of the most deployed version of Windows (Win 7) and that unsurprisingly nobody wants to use. Pure sabotage, which is sad because the development tools are great (Visual Studio is my favorite IDE by far).
I know. But in my opinion it's not just that they read the leaves, it's also they push their own platform towards irrelevance and thus the whole situation is a kind of self-fulfilling prophecy.
In comparison to say WPF, the web stack was very lacking. It wasn't for example until a few years ago that we got CSS grids. Heck, HTML components are still not mainstream, despite solving a very problem... which doesn't elsewhere.
Man have they been slow to make progress on that. I first started hearing about it early 2018 and here we are nearly two full years later and it still seems extremely raw. Maybe it will start moving faster now that Core 3.1 has shipped but the pace of progress doesn't give me confidence in Blazor.
> Microsoft still didn't address the biggest pain point for desktop applications: the lack of a multi-platform UI framework
With the current state of the tech it would be Qt (very awkward for the web though, using WASM?), or a modern web framwework with a design framework (e.g. Angular + Material Design) inside native wrappers. I don't see how MS could step in with some silver bullet solution.
Is this really the biggest pain point? I'm not sure this is a dire need for most businesses. WPF has a compatibility layer that allows developers to use it with .NET Core on Windows. Xamarin.macOS exists if you want the native look for macOS. There's already GTK bindings if you need something cross-platform, and a variety of other OSS projects (Avalonia and Eto come to mind, but I know there are others).
I'm just not sure x-plat desktop is a place where MS needed to step in to fill the void.
This schism cuts from both sides: have one dependency that hasn't been updated to support Core and you can't upgrade and then you can't use anything new.
Many of Microsoft's own libraries such as Sharepoint and Dynamics don't support Core and many don't even have clear signalled intention to do so.
Classic "big bang flag day, break compatibility" problems.
>have one dependency that hasn't been updated to support Core and you can't upgrade and then you can't use anything new.
Can you give any examples?
Generally, .NET Standard aims to fix the problem. If you upgrade to .NET 4.8(or atleast .NET 4.7.2), you can use libraries targetting .NET Standard v2.0(and below)
So, new libraries can support both NET Framework. (Unless the authors don't want to Or can't)
It is not a perfect solution as library maintainers need to put effort into migrating to NET Standard. But if library authors have not done it by now, then perhaps you should use a different library
> It is not a perfect solution as library maintainers need to put effort into migrating to NET Standard. But if library authors have not done it by now, then perhaps you should use a different library
The effort isn't very difficult in my experience; switch CSPROJ formats, edit the file to be multi-framework, rinse repeat. Your build scripts and/or CI pipeline will probably be where more of the work is.
That said...
>>have one dependency that hasn't been updated to support Core and you can't upgrade and then you can't use anything new.
> So, new libraries can support both NET Framework. (Unless the authors don't want to Or can't)
It's possible, yes.
The more "active", smaller, newer libraries are already starting to get sick of this and remove support for Framework. ASP.NET for example.
Further compounding the situation is when libraries take it as an opportunity to make compatibility breaks themselves. Some MS examples include Powershell, ASP.NET and Entity Framework.
The author seems to make a rather classic mistake; once told, I'm sure you'll recognize it in some of your current and past coworkers: they become intimately involved and emotionally invested in the evolution of their chosen toolkit.
In C++, which has a large community with this particular affliction, this usually means their code stops compiling with anything but a HEAD clang targeting C++20 and becomes utterly unrecognizable. In C#, following this post, a few framework gimmicks will apparently not be implemented in the old .NET: all code must utilize them or risk "exodus".
Java had a good immunization protocol: don't change the language for 10 years. All those people moved to Scala.
Meanwhile, of course, the real world continues to run just fine with ancient software written in ancient languages compiled with ancient tooling, targeting ancient operating systems. Your router is on Linux 2.6. Hell, you can start a new application targeting .NET Framework 4 today and Microsoft will keep that stuff running for another 20 years on Windows.
No, the problem is that their dependencies will use the new gimmicks, and if they need feature or security updates in those dependencies, they will need to migrate their applications to the new platform.
I've been using .NET Core for new projects since it first came out, and I think it's important to remember that a couple years back .NET Core wasn't really stable enough for production use (in comparison to .NET Framework). The original project files were in a different format, you often had to fight the tooling, and important libraries like Entity Framework were missing key features. Despite that, the fact that Linux was a target platform made the whole thing worth it.
Core 2.0 came out mid 2017, and in my mind I still wasn't sure .NET Core had cooled down enough to port applications from .NET Framework. 2.0 turned out to largely be stable enough for production, but there wasn't really any way of knowing that without watching it for a few years.
We've only just gotten to the point where moving an important production code base to .NET core actually feels like the correct thing to do. I'm sure there will still be some hurdles involved, but at least there won't be too many landmines.
> have one dependency that hasn't been updated to support Core and you can't upgrade and then you can't use anything new.
That's not true. Friction in tooling and project description files does not really equate to instability for production use - "worth it" is quite subjective and also not equatable to stable. As you said, Core v2 was already out 2 years ago, and plenty of people were using Core v1.X in production on significant sites without much trouble.
Microsoft are going to support .net 4.8 untill the end of time. Nothing to worry about. Only if you want new stuff that will only come in 5.0 will you require the migration.
This rather misses the point of the article. The article states that ALTHOUGH Microsoft will continue to support .NET Framework 4.8 effectively forever, OSS authors will not.
That's not really how it works in practice in my experience. In some time, some thing you use needs to be patched and the latest version only runs on the newer platform.
Doesn't matter if the underlying platform is supported if the entire ecosystem moved elsewhere.
The most recent versions of the .NET Framework (including 4.8, the final version) are supported for as long as the OS they are installed on is supported.
I think that because of that longevity, you're going to see lots of the main libraries etc. supporting .NET Framework for years to come.
Developing to the right .NET Standard spec will ensure compatibility between ‘old’ .NET Core and the legacy .NET Framework 4.8. Libraries that do so would be limited in their ability to use new language and framework features though.
