.NET Team Survey: Native AOT
github.com
github.com
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!
.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.
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.
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.
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.