I’ve been a C# developer for two (almost) decades, how do people even keep up with these rapid changes in the post Core world and what/when to use them? This is a serious question by the way.
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.
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.
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.
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 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.
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!
>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.
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?
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.
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.
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?!
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.
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).
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.
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.
> 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.)
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.
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 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.
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.
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.
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".
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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 built a high end desktop after exclusively using desktops for a decade because Unity WebGL builds are so awful. It is the slowest, most opaque and buggiest build chain I have used since I made Flash games.
I expect it would replace the need for the burst compiler, and likely reduce the complexity of the job system (especially its need for special types.) There is also an observed performance gain switching from IL2CPP to CoreRT, which would be 100% free.
Why should they, IL2CPP and Burst compilers is able to do C++ like optimizations that .NET is still far from being able to (they have actually two nowadays).
.NET 5 also doesn't run in all platforms that Unity targets.
Rich ecosystems only have to gain from multiple implementations.
> IL2CPP and Burst compilers is able to do C++ like optimizations that .NET is still far from being able to
This is a discussion about .NET AOT (CoreRT) which has been observed to have a considerable performance benefit over IL2CPP/burst (see the attached blog post in my original comment)
> .NET 5 also doesn't run in all platforms that Unity targets.
CoreRT supports C++ codegen, so in the worst case you can use that. But its first class platform support is growing. Though I suspect even then you may see some platform support differences but those can be ironed out. Given the benefits of switching to .NET CoreRT I suspect it would be worthwhile.
I doubt it, given that Burst does optimizations, with a constrained C# subset tailored for replacing lower Unity layers previously written in C++, and is already being used in production.
CoreRT is still a preview tech that has to deal with the full capabilities of .NET Framework, including VB.NET, C#, F# and C++/CLI as generators of MSIL bytecode.
Unfortunately reflection is so widely used in .Net libraries and core frameworks that code removal during linking becomes more or a less impossible without spending A LONG TIME decorating an xml file with code removal exceptions. I have done it on Xamarin iOS, it is not fun. So one of the prime dreams of having .net AOT of having an easy way to create a COMPACT self contained native exectuable dies when it hits real code.
Source generators may solve that going forward, but that is going to take years to filter out to nuget library land.
There are other advantages of AOT, sure, but I think R2R that is in .Net already covers a lot of those.
They need to solve the poor linkability of .Net code first IMO. I think Microsoft realise that, especially if they want Blazor client side to work.
Reflection is not "unfortunate". Actually, it is quite helpful when used right. And there is a way to shove it with AOT.
I've tried to communicate that to some team members but got the impression they weren't so interested in solving that. Or maybe they are reluctant to take a solution from 3rd party, preferring to quickly come up with in-house code instead.
Well, this would clearly cost them at least 5 years of R&D given they are able to find the right PhDs in math and compiler theory who are able to crack that.
As for source code generators as a way to solve the reflection dilemma: they are not going to make a dent as they tied to the specific language (C#), and not to .NET platform as a whole. This makes them somewhat fragile and largely fragmented in the eyes of component vendors.
> As for source code generators as a way to solve the reflection dilemma: they are not going to make a dent as they tied to the specific language (C#), and not to .NET platform as a whole.
Slight correction: source generators are a _compiler_ feature not a _language_ feature. This may seem like a meaningless distinction, but you can use source generators in _any_ C# project provided your compiler is new enough. You can easily use generators in a .NET 3.5/C# 5 project if you want.
> So one of the prime dreams of having .net AOT of having an easy way to create a COMPACT self contained native exectuable dies when it hits real code.
102 comments
[ 3.3 ms ] story [ 192 ms ] threadThe 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!
.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.
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.
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.
What did you need to do to create an empty website?
Disclaimer: I work on ASP.NET Core
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.
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
The minimalist projects don't do "code-behind" at all.
When run all it does is return "Hello World!" in plain text - it doesn't even use HTML.
dotnet new empty ?
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 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.
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?!
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.
Even with its half broken implementations, .NET and Java are still the best options in tooling and managed runtime capabilities.
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.
Flutter is Dart Rails, the last hope to save Dart.
https://opensilver.net/
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.
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.
(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.)
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.
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.
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
If you want to start a project from scratch, sure Core/5 is nice.
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?
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.
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.
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.
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 .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".
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
Sure, but that is beside the point. You don't make legacy code disappear just by wishing it away.
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.
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.
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?
Being cross platform is an nice side effect of the whole rebooting process.
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.
https://github.com/dotnet/runtime/issues/35318
coreclr.dll is currently half a megabyte smaller than the 3.1 release.
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.
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
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.
Be happy you are not a Rust developer then ;)
https://docs.microsoft.com/en-us/dotnet/standard/choosing-co...
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
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.
(see https://devblogs.microsoft.com/dotnet/introducing-net-5/)
That's not true.
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.
"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...
C# 9 is next on the list.
Edit: interesting, someone wrote about this a couple years ago: https://xoofx.com/blog/2018/04/06/porting-unity-to-coreclr
I wonder if there’s movement on this internally at Unity.
I agree the the Users of Unity may or not see gains in the short term
.NET 5 also doesn't run in all platforms that Unity targets.
Rich ecosystems only have to gain from multiple implementations.
This is a discussion about .NET AOT (CoreRT) which has been observed to have a considerable performance benefit over IL2CPP/burst (see the attached blog post in my original comment)
> .NET 5 also doesn't run in all platforms that Unity targets.
CoreRT supports C++ codegen, so in the worst case you can use that. But its first class platform support is growing. Though I suspect even then you may see some platform support differences but those can be ironed out. Given the benefits of switching to .NET CoreRT I suspect it would be worthwhile.
CoreRT is still a preview tech that has to deal with the full capabilities of .NET Framework, including VB.NET, C#, F# and C++/CLI as generators of MSIL bytecode.
Source generators may solve that going forward, but that is going to take years to filter out to nuget library land.
There are other advantages of AOT, sure, but I think R2R that is in .Net already covers a lot of those.
They need to solve the poor linkability of .Net code first IMO. I think Microsoft realise that, especially if they want Blazor client side to work.
I've tried to communicate that to some team members but got the impression they weren't so interested in solving that. Or maybe they are reluctant to take a solution from 3rd party, preferring to quickly come up with in-house code instead.
Well, this would clearly cost them at least 5 years of R&D given they are able to find the right PhDs in math and compiler theory who are able to crack that.
As for source code generators as a way to solve the reflection dilemma: they are not going to make a dent as they tied to the specific language (C#), and not to .NET platform as a whole. This makes them somewhat fragile and largely fragmented in the eyes of component vendors.
Slight correction: source generators are a _compiler_ feature not a _language_ feature. This may seem like a meaningless distinction, but you can use source generators in _any_ C# project provided your compiler is new enough. You can easily use generators in a .NET 3.5/C# 5 project if you want.
They are working on improving that: https://github.com/dotnet/designs/blob/master/accepted/2020/...
There's just easier languages to do it in if you really need AOT.