I've honestly given up. The new "open" development style of .NET Core is not my cup of tea. It's now riddled with MVP features that are 80% complete, bug-ridden, and undocumented other than couple of blog articles.

The compatibility break with the .NET Framework also removed the biggest advantage I saw in C#, which was that any code that I wrote would "just work". Now there's more frameworks, standards, cores, and build flags than I care to learn, and there are all too many scenarios where it's flat impossible to do something that was trivial before.

This is the reason, for example, that PowerShell Core is past version 7 but is still missing many modules, including some key Microsoft ones. If they can't figure this out, what chance do I have? Why would I bother?

Lastly, I got fed up with Microsoft releasing yet another half-baked GUI framework. What's the latest one? MAUI? It's yet another attempt at having one framework to rule them all, which means that it'll inevitably be the lowest common denominator and not good at anything. Microsoft won't actually bother making it good enough to write a flagship application in it, and they won't write any of their own apps with it. It'll be dropped on the floor and replaced by the next incomplete GUI framework within just a few years, mark my words. That's if it's ever finished!

> The compatibility break with the .NET Framework also removed the biggest advantage I saw in C#

I'll be honest here. The migration from .NET Framework to .NET Core is a pain. I see why things were done the way they were done, but it's still a real pain.

That said: for green-field works NET Core is clearly superior.

> PowerShell Core is past version 7 but is still missing many modules, including some key Microsoft ones

Just like .NET Core's main mission was not to replace the entire .NET Framework, the same applies to PowerShell Core.

.NET Core was created to make developing .NET-based web/cloud-services easier, faster, using less space/resources at runtime, and to have a fully supported cross-platform story. And at that it has been a wild success.

Almost everything about .NET Core is better to work with than the traditional .NET Framework (at least for the workloads it was intended for), and I'm always depressed when I have to move back to work on the "old" stack.

In this regard PowerShell Core is (as I see it) not meant to fully replace regular PowerShell either, but to be a good platform to do your cross-platform dev-ops'y build and deployment scripts related to your .NET Core deliverables.

It may not be what you want it to be, but it has a clear mission, and it's delivering fairly well on that.

> Lastly, I got fed up with Microsoft releasing yet another half-baked GUI framework.

I think this applies to pretty much everyone, which is why they never catch on, and Microsoft inevitably trying to "solve" this by releasing yet another framework.

That said the MAUI-presentation on this year's Build looked pretty convincing. If I had time to spare and had some small projects/POCs I had to work on, I might had given it a spin.

But if .NET Core was not meant to replace the .NET Framework, why is Microsoft doing just that with .NET 5?

(Yes, the old framework will still exist after it's been replaced - the same way VB 6 still exists after being replaced by VB.NET and IE still exists after being replaced by Edge.)

I believe Core stated as a minimal runtime for running Asp.net on other platforms than Windows. It was understood that this would not be fully compatible with the standard framework which was too coupled to Windows.

But somewhere along the way it was decided that the core platform was the future and where all future improvement will happen. This leaves all .net framework code on a dead end platform. They will not be able to take advantage of any new improvement or even the new versions of C#.

I don't think MS deliberately decided to break backwards compatibility in .net. It just sort of happened because the core project got out of control.

> It just sort of happened because the core project got out of control.

A more accurate representation of events would be that .NET Core suddenly fueled a huge interest and growth in .NET as a platform which it hadn't seen in a long time (it was actually in decline!).

Microsoft probably decided that for the overall, long-term health of the .NET platform it was more important to cater to these new users, than maintaining the status quo for the existing users, some which were already considering leaving ship.

Looking back right now, it certainly looks like that was the right decision to make.

There is no doubt multi-platform support is great for ASP.Net. The problem is that MS has coupled everything. So to take advantage of the newest version of C# you have to migrate to the platform-independent framework which may not support all libraries you are currently using. This is absurd - why are these things coupled? If I maintain some internal tool using windows forms I have no desire to rewrite to support Unix - but if I don't, I am stuck on an abandoned platform.

I think it comes down to Core was not conceived as the next version of .net but as an alternative runtime for a specialized purpose. So attention was not paid to decoupling or backwards compatibility or migration paths. And now we have a disaster which will dwarf the python 2/3 conundrum.

> And now we have a disaster which will dwarf the python 2/3 conundrum.

Given that Python 3 has been around for 12 years now, and still doesn't have universal adoption, I kinda doubt this is going to be near as bad a migration as that was.

At least .NET 5 will have compatible string-types once you've upgraded your projects :)

> Given that Python 3 has been around for 12 years now, and still doesn't have universal adoption, I kinda doubt this is going to be near as bad a migration as that was.

Given that .net is much more entrenched than Python was 12 years ago, I think it going to take a lot longer! Frameworks like WebForms and WCF will not be ported, so projects depending on these will require massive rewrites. This a lot more work than fixing string encodings and putting parentheses after "print".

> Frameworks like WebForms and WCF not be ported

WebForms is terrible and I see no reason for anyone to pull that monstrosity of a "I wish we had a VB/Windows WYSIWYG app-editor for the web" impedance-mismatch into a new codebase.

Applications which haven't migrated off WebForms yet, probably have little to gain by moving to .NET Core anyway.

WCF has been open-sourced[1] and ported (at least the client libraries) and you have separate community-projects[2] working on porting the rest of the stack to be compatible and usable with .NET Core.

If the community really want's to go full WCF on the new stack, they are empowered to do so.

[1] https://github.com/dotnet/wcf

[2] https://github.com/CoreWCF/CoreWCF

> WebForms is terrible

Sure, but that is beside the point. You don't make legacy code disappear just by wishing it away.

You are allowed to change your mind, aren't you? :)

The goal for the initial .NET Core project was to have something cross-platform, modular and lightweight to build Linux-deployable cloud-services with.

Once that reached a mature state, they could expand scope.

And now, after .NET Core 3.x has landed, it has matured so much, that MS can see one single unified path forward which also includes some things which previously was only possible using the traditional .NET Framework (4.8).

So now they are adding those use-cases to the "Core" package as well, without compromising on what .NET Core was supposed to deliver. I honestly don't see anything wrong with that.

The problem is it leaves all .net framework code on a dead-end platform. For all previous .net versions, code could be easily and safely upgraded to the next version because they were largely backwards compatible. But you can't easily upgrade existing code from 4.8 to 5.

If you want to start a project from scratch, sure Core/5 is nice.

> For all previous .net versions, code could be easily and safely upgraded to the next version because they were largely backwards compatible. But you can't easily upgrade existing code from 4.8 to 5.

As someone who has been working with .NET since the first release: tell me about it! I fully concur. I don't deny this, nor excuse it.

That said, I believe that once Microsoft decided that it was OK to break compatibility, they managed to improve upon lots of things which up until that point had become fairly painful on the traditional .NET Framework.

You win some, you lose some, I guess?

Business logic ports over really well - we have been able to effectively copy and paste code and the corresponding tests between a legacy .NET Framework WinForms app and .NET Core 2.0 and later service (WebAPI or gRPC) and it mostly just works. The trouble comes when the code integrates heavily with a UI stack - that’s a lot more work to port over. It was pretty hard before .NET core 2 though. But .NET 4.8 will be supported as long as Windows 10 is - probably at least another 10 years or more.

Right, but I think the complaint was that it was still immature and missing some use-cases covered by the old framework.

Anyway, I do hope they succeed and the .NET 5 unification goes smoothly. I want those C# 9 features - but I also need some old third-party libraries to keep working.

Which ones, if you don't mind me asking out of curiosity?

Which features? Mostly data classes, a.k.a. records, and (from C# 8) non-nullable references. Kotlin has had these features for years and it makes things so much easier and cleaner IMHO.

I believe they tried to keep the C# version independently from the framework version, so people can use the new C# version on a old .net framework.

But things seem impossible for some new features, for example async steam just need new feature from core CLR.

So after .C#8, they decide only to support it on .NET core

The problem is not the "open" development.

The actual issue is this new Microsoft full of half-done projects and trying to reduce engineering costs. They even try to make others write the documentation for their products... MSDN is gone and now docs are a mess.

Ballmer was a mess, but at least he got the devs-first bit right. Nowadays it is devs-last, cloud-first.

Here I have to sadly agree, but I think the cause is something else. Lots of new blood full with ideas to leave their mark.

MAUI is Xamarin rebranded.

Even with its half broken implementations, .NET and Java are still the best options in tooling and managed runtime capabilities.

And it will be crap. What I want, and I'm sure a lot of other devs interested in making C# GUI multi-platform apps, is an UI framework à la Flutter that display the same thing everywhere. In the days of Electron apps not having a native look and feel is not a really problem anymore.

The saddest thing is that Microsoft actually offered that years before: Silverlight Out-of-Browser applications, that where running the same on Windows and Mac OS.

Silverlight was good for it's time but nowadays I would rather code in whatever popular JS/HTML framework - the live reload beats any C# flow hands down in iteration time and the fact that I can just reverse proxy my local dev env while working on something to a designer speeds up design tweaks a bunch.

Or just use OpenSilver, thanks WebAssembly.

https://opensilver.net/

That sounds like it would make the development iteration even more terrible than it was - WASM builds were slooow last time I tried it - with webpack in HMR mode or flutter you get instant feedback - this is probably the biggest productivity boost in UI development - I've yet to see anything from .NET offer similar performance, I suspect it would be challenging due to the static nature of IL.

Electron is just a phase like Active Desktop and XUL, its time is coming to pass in this fashion driven industry.

Flutter is Dart Rails, the last hope to save Dart.

What you’ve just described is absolutely the opposite of what I want.

Mobile apps have very different requirements than desktop apps, not least as the metaphors are wildly different.

macOS, Windows and X all have fairly similar window layouts and behaviours.

iOS and Android have sharply different layouts and behaviours. Yeah there’s a bit of overlap now, but even navigation is different.

There are rumours of a Flutter back-end coming for Xamarin.Forms/MAUI. Or possibly a something lower level in Windows itself (which a MAUI back-end could tap into).

If it was just marketing name change, it would be available now. Their current timeline has the first production release in late 2021!

It cannot be available now, because Xamarin doesn't support all backends that MAUI should support, nor does it run properly on .NET 5 yet.

>The new "open" development style of .NET Core is not my cup of tea. It's now riddled with MVP features that are 80% complete, bug-ridden, and undocumented other than couple of blog articles.

.NET Framework is a product, .NET Core is a OSS project.

When .NET 5 will ship it will be even worse since .NET Framework people will just expect things to work.

> It's now riddled with MVP features that are 80% complete, bug-ridden, and undocumented other than couple of blog articles

I work full time with ASP .NET Core 3.1 projects, and I don't recognise this at all. I don't think that it's correct.

Same here, this is just utter nonsense. I have to assume the person that wrote that comment hadn't actually been using dotnet Core at all. I note how they provide no examples of bugs from this "bug-ridden" and "undocumented" platform.

I've been using dotnet since it was originally created many moons ago, and dotnet core is the best incarnation yet. Documentation is excellent - I don't think I've ever once came across an undocumented feature?!

> dotnet core is the best incarnation yet.

To be fair, we didn't use .NET Core extensively before .NET Core 2.1, because it was not quite ready yet. But since 2.1, we haven't looked back.

Same here. Generic hateful statement from a developer that probably has spent a couple of days at most in .NET.

I suspect a lot of people (myself included) will just stop at 4.8.

Just this week I wanted to spin up a minimalist ASP.NET page for "tyre-kicking" of new infra builds. You know, something that just coughs up a single page with some basic info, such as the regional options, time zone, current time, and the latency to the SQL Server. This checks that the infra guys did their job and that the AD accounts and firewall ports are in place.

I wanted to write 1 page with just some dynamic labels, that's it. Nothing fancy. No MVC. No dependency injection. No JavaScript frameworks. No CSS. Just one ASPX or CSHTML page.

Visual Studio 2019 no longer ships with a web project template that does that. Every single project type coughs up megabytes of crap and a bunch of scaffolding.

After hours of clicking through every project type, I resorted to another hour of googling to discover that the "legacy" empty templates are still there, but only available as a hidden install option!

It's madness.

It is strange that you couldn't find the empty web template. Every version of ASP.NET Core has come with one. Empty is the first option in the "Create a new ASP.NET Core web application" dialog in VS2019, and "dotnet new web" creates an empty website via the command line.

What did you need to do to create an empty website?

Disclaimer: I work on ASP.NET Core

The most minimalist ASP.NET Core template I could find made it too difficult to create a "page" with some code-behind.

I could create a CSHTML page and inline expressions worked, but I couldn't convince it to execute anything from a matching cs class.

I did google this, and it's not like I hadn't written Razor syntax pages before, but that was a few years ago and my memory was fuzzy.

What I found was that Razor pages are now part of any number of very similar sounding but wildly different frameworks, and code samples for one do literally nothing in the other. It's not even self-evident which framework I'm "in" for any given project. Half of it seems to be just convention, the other half is explicit configuration, and it's all version specific.

I tried to go back to classic ASP.NET, thinking that that's actually a better fit for the type of legacy web app server testing that I need to do. That's where I found the new project templates that pull in more code by default into an "empty" project than I've written in the past half a decade.

> The most minimalist ASP.NET Core template I could find made it too difficult to create a "page" with some code-behind.

The minimalist projects don't do "code-behind" at all.

"self-evident which framework I'm "in" for any given project"

Has that changed? It's in the project properties in Visual Studio where I think it's been for as long as I can remember?

NB I've been using .Net for about 15 years and quite happily using .Net Core 3.1

>No dependency injection. No JavaScript frameworks. >Visual Studio 2019 no longer ships with a web project template that does that. Every single project type coughs up megabytes of crap and a bunch of scaffolding.

Yeah, the way depency injection and multiple JS frameworks are shoved down your throat in .NET Core is sooo annoying.

> Yeah, the way depency injection and multiple JS frameworks are shoved down your throat in .NET Core is sooo annoying

I've been using dotnet core for years and precisely zero times I have had any JS framework shoved down my throat.

Not sure how you miss the Empty project template: https://i2.wp.com/anthonygiretti.com/wp-content/uploads/2020...

With the new request handling pipeline you hardly need a template for a single page diagnostic.

https://anthonygiretti.com/2020/06/29/nano-services-with-asp...

I had VS 2019 open and tried this - creating an empty project is the first entry on the list of templates - all it contains is a minimal Program.cs and Startup.cs - nothing else.

When run all it does is return "Hello World!" in plain text - it doesn't even use HTML.

GP is not talking about an empty app project.

It's a minimalist web app that responds to HTTP requests without using MVC, not a console app?

dotnet new web ?

dotnet new empty ?

Is MAUI the death knell for Project Reunion?

MAUI on Windows is based on WinUI, so no. Those projects are orthogonal.

Everything is optional, you can still code in C# like you did years ago and there's nothing wrong with it.

I look at the new things and take what I like. For example I particularly dislike the async / await paradigm so I still use background workers (and they work absolutely fine for my needs).

Linq is sublime (I know it's already "old") : I wasn't convinced at first but now I wonder how people in other languages manage without it !

Some things are just syntactic sugar but are very practical : the ?? and .? operators, new MyOjbect { Property1 = 15}; etc etc

I'm sure there are a lot of things I don't know about the language but it's fine, i will find it when I need it.

Last week I needed to define a method body at the creation of the object and not in the class. After some lengthy googling because I didn't know how to put words on what I was looking for, I found that C# had Func and it solved my problem beautifully.

This is about being able to use the language/framework you already know to compile to pure native binaries (like Rust, but with GC). It's a big deal since it makes C# viable in places where it isn't currently, like a lot of Go's use cases.

I had been away from C# for nearly 6 years, but was able to pick up Core in a couple of days. If anything, things have gotten simpler and there's fairly good cross platform support. What rapid changes are you referring to?

C# has long supported it on UWP side, but now with .NET 5 there is an ongoing discussion if they will still support it or not.

The whole MDIL (Windows 8/8.1) and .NET Native (Windows 10) came from WinDev, not DevDiv, hence why it has its own idiosyncratics regarding .NET support.

Now with .NET 5, it seems they are gearing towards just a better NGEN, thus shipping a kind of AOT/JIT mixed mode image, which isn't being that well received and most likely the survey to feel the community.

Interesting, they are removing WinRT support from .NET 5 CoreCLR and instead adding a system that lets the Windows team plug in the marshaling stuff:

https://github.com/dotnet/runtime/issues/35318

coreclr.dll is currently half a megabyte smaller than the 3.1 release.

It is based on the same ideas as C++/WinRT, which I am still bitter about, because it represents a productivity drop versus C++/CX as the ones pushing for it are hoping that ISO C++23 eventually gets the features that enables the VS tooling with C++/CX today.

So you are back to manually copying files around and writing IDL files with Notepad like experience as if using ATL style development in 2020.

Most likely C#/WinRT seems to follow the same fate in productivity drop.

That was a requirement twenty years ago when the framework wasn't bundled in the operating system and download speeds were much slower. It's really a non-issue now.

The whole point of .NET Core is to bundle the framework with the application.

I thought the whole point was to become cross platform. You can install the runtime on its own. Bundling an application and the framework isn't a requirement.

Or maybe there isn't a single "the whole point" and it can be useful for different reasons to different people?

Some .NET Framework libraries that were ported to .NET Core are never going to stop being Windows only.

Being cross platform is an nice side effect of the whole rebooting process.

You probably shouldn't, your customers won't notice. Joel Spolsky wrote a brilliant essay on this:

https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

Although I don't identify with the "fire" part of that analogy, I agree it seems excessive to keep up with all the fine technical details of new features.

Programming language improvements can, at best, give us small decreases in accidental complexity.

Good software engineering practises (ruthless prioritisation, proper modularisation, continuous integration) etc. can have huge effects on both inherent and accidental complexity. It is much more important to spend time on those things. They are independent of specific programming language features.

Keep in mind that, although I partially agree with you, other platforms are way-worse than .NET. think about nodejs mess and client-side ecosystem, where things break almost at any minor release. Dev world is going fast, and I think that the choice for .NET is to embrace change or die as an old platform. My2Cents.

Your comment about the JavaScript client side ecosystem is fair, and I could even provide numerous examples of libraries introducing breaking api changes in minor releases.

However it is unfair and simply untrue to somehow also tar nodejs with that brush. Upgrading a nodejs project by a major version usually never needs any code changes

> how do people even keep up with these rapid changes in the post Core world and what/when to use them?

You wished that the dev world moved slower. Sorry, things move fast nowadays. The .NET team decided to stay relevant, by moving fast to keep up. That's just how it is.

As a desktop developer I really miss the Big Bang releases and slow pace yes. We are doing a 2-year transition between 4.7.1 and 4.7.2 now! What goes on beyond that is just a fog. Some of our third party dependencies are probably never going to be ported core while many others are starting to lose maintenance on netfx. Being in the position of having to maintain a netfx desktop app for the coming 10-20 years is looking bleak.

Then stay on the LTS releases. They come roughly annually.

Starting with .Net 5, there will be one major release exactly once a year, and one LTS release exactly once every two years.

(see https://devblogs.microsoft.com/dotnet/introducing-net-5/)

.NET 5 is a no go for those of us who are stuck on netfx. There is no compatibility.

> There is no compatibility

That's not true.

I mean for existing pre-built binary libraries built for netfx (which is what we are stuck with as dependencies in many cases) there is no way to use them under core/net5 that I’m aware of (I’d be happy to learn that it was!).

E.g I have a huge library from Autodesk that targets 4.6.2 and I consume it from 4.7.1 now. I don’t think they have a plan to support a Core/net5 framework so my app can’t either.

Obviously you can rebuild libraries and target both/netstandard/whatever but that’s not what I mean.

There is actually a compatibility mode[1], although not everything is supported:

"Starting with .NET Standard 2.0, the .NET Framework compatibility mode was introduced. This compatibility mode allows .NET Standard and .NET Core projects to reference .NET Framework libraries. Referencing .NET Framework libraries doesn't work for all projects, such as if the library uses Windows Presentation Foundation (WPF) APIs, but it does unblock many porting scenarios."

I don't know if there are downsides or if the compatibility will be removed in the future.

https://docs.microsoft.com/en-us/dotnet/core/porting/third-p...

Seems to me more like the issue is with Autodesk and with an unmaintained binary dependency, not with .NET at all.

The problem isn’t the framework so much as libraries and their dependencies. A required update to one library might require a bump in a second library and that library drops netfx support and supports only core/net5 in that bumped version. Stuck between a rock and a hard place.

For the new language feature is usually look them up when there's a new release and try to use them in any new code I write. And since I'm a resharper user, it usually suggests code rewrite using new language features.

Asides from the obvious blog posts, Microsoft hosts many events such as Microsoft Ignite, where companies often send a couple of developers to get up-to-date with what is going on in the MS world, C# included.

By spending part of my learning budget on MSDN blogs, Channel 9, MSBUILD and Ignite sessions.

> how do people even keep up with these rapid changes

Be happy you are not a Rust developer then ;)

Microsoft do try and explain when to choose between .Net Framework and .Net Core for server side applications:

https://docs.microsoft.com/en-us/dotnet/standard/choosing-co...

Every (halve? ) year I check the just c# release notes and create an application that incorporates the new things.

C# 9 is next on the list.

The most difficult thing about keeping pace with dotnet world is the seemingly infinite variations and naming conventions.

another lazy "developer" who can't keep up with the newest trends. Real developers are working 365 days a year, around the clock, and don't waste time with girlfriends etc... You will never be one of them.

I don’t think anyone does. I think greenfield projects use the latest version but existing projects just stay where they are barring critical issues. I know my company is still on .NET 4.6 and has no plans to migrate to .NET Core 2 Duo.