Why is .net core not taking the world by storm ? Because most 'real .net devs' still work on .NET 4.x legacy windows apps.
Edit: can anyone give me the one-paragraph rational for why Net Core should take the world by storm? C# is a nice language and I'm a mostly happy VS user (except when I have to fiddle with MSBuild), but why should I go in and change the dropdown from ".Net Framework 4.5.2" to ".Net Core"? Let alone why any user of, say, Python or Node should drop everything and come over to C#.
Honestly, .NET core makes a lot of sense for new projects that need to be highly scalable. If you have an API service that's hosted in a cloud provider, or a tool that generates PDFs of items, or a tool that scrapes API data and chucks it in a database, then this is great. These are simple applications that do not need an awful lot of authentication, crazy UI frameworks, or other windows-only features.
The code itself runs faster [1]. It might not matter for business / CRUD applications, but that's a nice to have thing.
The biggest selling point is cross platform support. Now, I don't care if the company switches from Windows 2016 VM's to some variation of RHEL. My code will work on that too. This gives your organization improved flexibility and reduced technical debt.
If you have a big legacy application using .NET Framework, it's probably not worth rewriting it for .NET Core. You will run into package conflicts. I have had to rewrite ".NET Framework only" pacakges to support .NET Core. That will throw your estimates off and probably delay the project. And that becomes really difficult to justify to project stakeholders.
[1]: https://www.ageofascent.com/2019/02/04/asp-net-core-saturati...
I tried 2-3 times up to and including .NET Standard 2.0 to switch and got burned by busted tooling and package conflicts every time. I’m starting a new project now and am still wary.
One of the major pains of my life as a .NET dev who does .NET core right now is Nuget and binding redirects!
This is why it is very interesting that the next "Core" release is to be called ".NET 5". No more "Framework", no more "Core". Simple version math applies: .NET 5 > .NET Framework v4.6.8 && .NET 5 > .NET Core 3.0. Maybe it will be less confusion all around, hopefully, soon.
Besides this future perspective, the real benefit from it you have today is that your project will (unless it uses Windows APIs, which is unfortunately way too common) instantly run on Linux.
1. The cost of moving a standard .NET application to .NET Core. If the benefit is there, it'll happen, but for established code bases I don't see why they'd bother when standard .NET works fine.
2. On the web side of things, many of the big content management systems aren't on .NET Core yet. Umbraco is the king of CMS's on .NET, and once they pull their finger out and focus on .NET Core I think we'll see a wave of developers moving to Core.
3. For general web stuff, there isn't a solid reason for people to move from the likes of Ruby, PHP, and Python to C#/.NET Core.
4. There's still a perception that .NET Core is a WIP. That's understandable, considering .NET has been battle-tested for decades, and .NET Core is still (relatively) new to the party. There was also the csproj issues from a while back, and that set off a few people from fully switching.
5. The naming has confused everyone, so the safe option is to wait for everything to sort itself out. .NET isn't going anywhere just yet, and the switch to .NET Core won't be a huge one for those that have had to adapt to new C# and .NET libraries over the years anyway.
The big difference for me is that many .NET shops rely heavily on certain libraries and tools, and many of them are very slow to adapt. Umbraco, as a prime example, recently upgraded to Angular 2 for its admin section, and is probably a year or two away from an initial move to .NET Core.
Especially .Net Core's dotnet command is a wonderful tool that allows you to do basically everything with it - it can run, compile, even run tests - completely on the command line.
.Net documentation is however VERY crusty in my experience - all the fragmentation and outdatedness can very well lead to you accidentally reading and trying documentation that is 3 major changes behind, for a library version that has long been replaced. Nowhere will you find any warnings. That is hugely frustrating.
Visual Studio itself also makes a very broken impression to me, although admittedly it appears to improve.
Not sure whether that's going to be enough to keep Windows or .Net alive in the long term, since even Microsoft is moving to embedded Web apps now, abandoning their own 3 different UI solutions they have been pushing in the last 20 years (completely ignoring the 3rd party efforts like platform.uno, which they could probably acquire quite easily - seriously: Xamarin, but not this?!).
> Because most 'real .net devs' still work on .NET 4.x legacy
I almost wish Microsoft would stop putting much effort into dead ends, however. It's going to be possible to use WPF and even Windows Forms after .net 5 transition (they'll be windows-only libraries). VB .NET is still kicking (just let it die already). I wish they would have folded all those person-hours into .net core stuff instead.
It is their escape route when they outgrow Excel/VBA.
https://devblogs.microsoft.com/dotnet/net-core-3-and-support...
For cross platform there isn't an official solution, the closest would be deploying as an Electron app.
There are other entirely community-supported/third-party efforts like Avalonia and Uno around as well.
It may change with the shift to open source but I'm not holding my breath.
The last GUI framework they entirely "left to rot" was Silverlight, and that was a) almost a decade ago now, and b) a fellow traveler in the XAML space where migrations were quite possible, if maybe not always easy/convenient, back to WPF or forward to UWP.
With the weeding of some of WinForms and WPF in recent .NET Core work, and the addition of XAML Islands, even what were the dead ends don't necessarily look so dead today, or at least not so rotten.
Microsoft may be encouraging Win32 apps in the store, but is clearly saying that Win32 is undead and they'll continue to support the zombie and stop trying to kill it. They hope people will move on and they are providing more tools than ever to help migrate from Win32 to UWP. It's now a much more nuanced migration rather than a forced all-or-nothing conversion.
Wikipedia pages refer to everything in the past tense. That's the encyclopedia tone they require.
The closest thing to a "new UI kit" announced at the last BUILD was the ground up rewrite of the Windows version of React Native to make it "extra-Native". That change is from UWP/C#/XAML to UWP/C++/XAML. It's still JS controlling UWP controls, it's just using C++ to glue together the controls rather than C#/.NET.
The next closest announcement to a "new UI kit" was that way more of the UWP UI stack (almost all of it) is being "lifted and shifted" out of being directly inside the Windows codebase and deeply coupled to Windows releases and being moved in the WinUI library. WinUI has always been the parts of the UWP UI shipped outside of Windows Releases. UWP is moving to a model where they want to have as much as possible inside WinUI rather than inside Windows to make it easier to ship UI controls updates to application developers without so much of the rigmarole of "this control will only be in Windows 10 19H2 and later" making it easier for developers to use the controls "now" rather than waiting for a future Windows feature update and less headaches between what is in a current LTS feature update versus most current feature update.
(The next closest announcement after that, was that the Fluent Design team was merging the design efforts of what they've been doing for UWP/WinUI and what the Office team has been doing for the Web in the Fabric libraries, moving Fabric to being much more "Fluent Web". It should not be a surprise that the web is important to Microsoft's UIs.)
https://github.com/microsoft/microsoft-ui-xaml/blob/master/d...
IMO, that means that. Net was never targeting the early adopter market. Ergo, their new platform, which is just different enough, isn't probably having many adopters. Secondly, having to wait for libraries to catch up is probably a real reason initially (till.net standard 2.0?) But that just meant when slower adoption.
Add to this, to maintain cross platform tooling, they're now have cli first tooling and flux around fileformats. That imo, made a lot of the traditional .net shops uncomfortable.
I've jumped b/w .net and Java and very comfy with Linux. Last few years have been. Net and .net core in prod. after 2.0+, it's been absolutely wonderful. Great language ergonomics and I can finally ditch vs for vs code. 3.0 is only going to make it better
But then, I'm probably far from the representative .net dev here.
I've been using standard 2.0 for new projects since it became available and building for dual deployment, either with Heroku or as a Windows service.
There's definitely a crowd of .net devs that doesn't care. They're probably not the ones on HN though. I've been holding my breathe waiting for all the libraries to catch up. We're so close!
I actually moved to .NET by choice for the Nemerle language a long time ago (C# mostly caught up, so I switched over). I might not be representative of everyone, but there's at least a subset of developers eagerly waiting on some small thing which will let them make the jump.
EF (not-Core) 6.3 has also been finally ported to .NET Core (though I think it is still considered "Preview" quality) which should be directly plug and play for some types of legacy applications (Microsoft seems hopeful it will mean more WinForms and WPF apps will just run on .NET Core now).
https://support.microsoft.com/en-gb/help/17455/lifecycle-faq...
Yep I know of a few places doing it.
Why isn't .NET taking over from python/node-with-typescript projects?
I haven't given net core 3 a trial yet but will use serial ports as my initial tests. In the 1.x and 2.x versions the serial port support was not up to the same level as the net framework.
Some of the .NET core stuff is pretty neat for basic demos to show off the tech. But for actual enterprise stuff I've so far found it really frustrating to work with.
There's no need to rewrite working .NET Framework apps, but .NET Core has seen massive uptake with cross-platform development and runtime, incredible performance, and interoperability with just about every other common open source languages and projects.