.Net 5 Freakin Annoying
-
Before the release of .NET 6: 1) Do you want support longer than 3 months? If so, use .NET Core 3.1 or .NET Framework 4.8 2) Do you want to receive security updates through Windows updates? If so, use .NET 5 or .NET Framework 4.8. 3) Do you want to use latest Open API standard? If so, use .NET 3.1 or 5.0. Ehh...
You missed one: 4) Do you want to use SQL Server Reporting Services? If so, use .NET Framework 4.8. The suggestion to develop a .NET Core report viewer[^] was "under review" for over 4 years, and was one of the highest-voted feedback items. Microsoft recently announced their plans for this: upgrade your reports to a Power BI Premium subscription[^]. Because paying them for the SQL Server license obviously wasn't enough money. :doh:
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
You missed one: 4) Do you want to use SQL Server Reporting Services? If so, use .NET Framework 4.8. The suggestion to develop a .NET Core report viewer[^] was "under review" for over 4 years, and was one of the highest-voted feedback items. Microsoft recently announced their plans for this: upgrade your reports to a Power BI Premium subscription[^]. Because paying them for the SQL Server license obviously wasn't enough money. :doh:
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
I am sure there are plenty of other things. Software development has pretty much been torn apart by some things moving too fast while others move too slow. If you build very simple things you can be in either camp and it will work. But if you need anything slightly complicated, you will be stuck between the two and productivity will go out the window.
-
you can suppress certain warnings in Visual Studio, if you want. Suppress warnings for projects and NuGet packages - Visual Studio (Windows) | Microsoft Docs[^]
I realize that (and I've done it), but having to do it now when it's been good for 20 years is annoying.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
I'd have thought it was more annoying that .NET 5 is only supported until May: Microsoft .NET and .NET Core - Microsoft Lifecycle | Microsoft Docs[^] The current "long-term support" version is .NET 6, which is supported until ... November 2024[^]. Turns out not having to rewrite everything every three years is yet another bonus to sticking with .NET Framework 4.8.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
And that's why instead of renewing my 14 years old knowledge of C# I decided to send MS to the Hell they belong and move to Python for my RAD activities. For all my other activities C++ is the pinnacle of high level but usually only C is viable, and Assembler becomes a not unreasonable tool.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
I'd have thought it was more annoying that .NET 5 is only supported until May: Microsoft .NET and .NET Core - Microsoft Lifecycle | Microsoft Docs[^] The current "long-term support" version is .NET 6, which is supported until ... November 2024[^]. Turns out not having to rewrite everything every three years is yet another bonus to sticking with .NET Framework 4.8.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
In this case, I don't have a choice. I have to use .Net Core because I'm doing an Avalonia app.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
It's screaming about a bunch of warnings that didn't crop up in .Net Framework. CS8600, 8601, 8602, and 8618. I see no benefit when the objects it's screaming about can in fact be null without hurting anything. In fact, my code is written to handle it gracefully. Nanny state bullsh|t...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013I second your opinion. In the Good Old Days, software was written by people, a significant percentage of whom knew what they were doing. Nowadays, programming has been opened to the "masses", so syntactic sugar and nannying compiler messages have become the norm. I recognize the utility of lint-like warnings - at times, they can catch some real howlers. However, they are not necessarily a good default for an experienced programmer who knows what he/she/it is doing.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
I'd have thought it was more annoying that .NET 5 is only supported until May: Microsoft .NET and .NET Core - Microsoft Lifecycle | Microsoft Docs[^] The current "long-term support" version is .NET 6, which is supported until ... November 2024[^]. Turns out not having to rewrite everything every three years is yet another bonus to sticking with .NET Framework 4.8.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
I'm seeing .Net 5 as a glorified beta release, where .Net 6 is the release version
Wrong is evil and must be defeated. - Jeff Ello
-
In this case, I don't have a choice. I have to use .Net Core because I'm doing an Avalonia app.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013This one?
Avalonia is supported on all platforms that support .NET Standard 2.0.
.NET Standard 2.0[^] includes .NET Framework 4.6.1 and up, although support is pretty rough for anything earlier than 4.7.2.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Open the .csproj file and change "the" line to read:
disableAnd yes, bloody annoying.Latest Articles:
ASP.NET Core Web API: Plugin Controllers and ServicesNo need to edit, that
Nullableswitch is available under Properties/Build/General :)Luc Pattyn [My Articles] The Windows 11 "taskbar" is disgusting. It should be at the left of the screen, with real icons, with text, progress, etc. They downgraded my developer PC to a bloody iPhone.
-
Just to add to my own argument.... Why should:
int i = null;
be an error and you have to write
int? i = null;
while
object obj = null;
is supposed to be OK? And yes, I understand the technical and historical reasons for this. And they are exactly that: technical and historical. The compiler can finally move us beyond this.
I disagree with this sentiment. I think that the way a variable is declared is very important to allow the compiler to check for misuse. Any misuse found would indicate that the programmer means something other than what he wrote.
The difficult we do right away... ...the impossible takes slightly longer.
-
I second your opinion. In the Good Old Days, software was written by people, a significant percentage of whom knew what they were doing. Nowadays, programming has been opened to the "masses", so syntactic sugar and nannying compiler messages have become the norm. I recognize the utility of lint-like warnings - at times, they can catch some real howlers. However, they are not necessarily a good default for an experienced programmer who knows what he/she/it is doing.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
I disagree, even an expert brain farts sometimes and the compiler warning you of that is, to me, useful to avoid bugs. And having the warnings in place can help in shared codebases, if you work alone sure, disable them. If it's shared I much prefer having them enabled and when you do weird stuff you disable it with a comment right there and not globally
-
It's screaming about a bunch of warnings that didn't crop up in .Net Framework. CS8600, 8601, 8602, and 8618. I see no benefit when the objects it's screaming about can in fact be null without hurting anything. In fact, my code is written to handle it gracefully. Nanny state bullsh|t...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013Disable explicit nullability, problem solved. If explicit nullability is your problem in the first place. If you don't know whether an object you just got passed to your function can be null, you have to program more defensively, than if you know it'll never be null (in that case, it'd get caught by the runtime if you declare this parameter as explicitly-not-null). Explicit nullability is one of those correctness features which you may just as well dread if you're not used to having a compiler look at your work, but is rather helpful once you learn to let the compiler do your job. If an object can, in fact, be null, then declare it as nullable. I got a plethora of both Object and Object? members in my current work project, those that can be null during error-free operation, are declared Object?, those that can't, are declared without the ? as I want the runtime to throw an error in an error case.
-
And that's why instead of renewing my 14 years old knowledge of C# I decided to send MS to the Hell they belong and move to Python for my RAD activities. For all my other activities C++ is the pinnacle of high level but usually only C is viable, and Assembler becomes a not unreasonable tool.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
Python? Aww, that is nice nest of hornets, if some external boundaries are enforced (like only using a version supported by the official repo of your distro) Good luck finding out what works how in 3.7, 3.9, 3.10.
-
I disagree with this sentiment. I think that the way a variable is declared is very important to allow the compiler to check for misuse. Any misuse found would indicate that the programmer means something other than what he wrote.
The difficult we do right away... ...the impossible takes slightly longer.
Either you misunderstood what I wrote, or I misunderstood you :confused: With nullable:
object? obj;
object obj;clearly indicate if "null" is an expected value. The "null" state is very useful - but also a very special - state, so these declarations allow the developer to clearly express if the null state is (or can be) used or not. Without nullable
object? obj;
covers both cases and the compiler has no way to help checking for what you refer to as misuse. Your first sentence indicates you disagree with this, but then the rest says the opposite?
-
I disagree, even an expert brain farts sometimes and the compiler warning you of that is, to me, useful to avoid bugs. And having the warnings in place can help in shared codebases, if you work alone sure, disable them. If it's shared I much prefer having them enabled and when you do weird stuff you disable it with a comment right there and not globally
I love Delphi 7's warnings of using platform-specific code - especially in the hindsight of how successful Delphi was on Linux and on .net.
-
Python? Aww, that is nice nest of hornets, if some external boundaries are enforced (like only using a version supported by the official repo of your distro) Good luck finding out what works how in 3.7, 3.9, 3.10.
Peter Adam wrote:
Good luck finding out what works how in 3.7, 3.9, 3.10.
Yrah it's a fast cycle VB, it's the VB3->VB4->VB5->VB6 transitions all over again. Though with mostly windows workstation or prepackaged runtimes for Linux it can be used without issues. It does require a process, that's for sure. Which is fine, in automotive we love processes and SPICEs.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
Disable explicit nullability, problem solved. If explicit nullability is your problem in the first place. If you don't know whether an object you just got passed to your function can be null, you have to program more defensively, than if you know it'll never be null (in that case, it'd get caught by the runtime if you declare this parameter as explicitly-not-null). Explicit nullability is one of those correctness features which you may just as well dread if you're not used to having a compiler look at your work, but is rather helpful once you learn to let the compiler do your job. If an object can, in fact, be null, then declare it as nullable. I got a plethora of both Object and Object? members in my current work project, those that can be null during error-free operation, are declared Object?, those that can't, are declared without the ? as I want the runtime to throw an error in an error case.
Yeah, and in my original message, I stated that I did that. The code I was trying to convert has been around for 10 years, and has been working flawlessly the entire time. I've already done the defensive coding that's needed. I've been coding for over 40 years. I think I know pretty much how to do this stuff. And making an object nullable doesn't mean you don't still have to check it before using it, so you gain nothing at all by making it nullable in terms of how much code you have to write.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
It's screaming about a bunch of warnings that didn't crop up in .Net Framework. CS8600, 8601, 8602, and 8618. I see no benefit when the objects it's screaming about can in fact be null without hurting anything. In fact, my code is written to handle it gracefully. Nanny state bullsh|t...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013this will come out not in the way I might intended but, just because it has been working for 20 years, does not mean I couldn't be reviewed, improved or changed. I had this on some code last month. some simple method, was confused by this new warning, but helped learned how there another way to write the code (for what ever .net compiler developer has decided it should be written their way) I don't like it, looks off, maybe ill come to shifting thinking, but hopefully for that set of developers that have yet to have the whole system fail over because of 1 null check missing in that 1 very very important, one of a kind situation, that this warning helps mitigate for them until they leave the project and is someone else problem then.
-
Yeah, and in my original message, I stated that I did that. The code I was trying to convert has been around for 10 years, and has been working flawlessly the entire time. I've already done the defensive coding that's needed. I've been coding for over 40 years. I think I know pretty much how to do this stuff. And making an object nullable doesn't mean you don't still have to check it before using it, so you gain nothing at all by making it nullable in terms of how much code you have to write.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013You don't have to check by making an object non-nullable. Suppose, I have a function Decode(List Buffer), not Decode(List? Buffer). Well, the moment a null gets passed to this function, the runtime throws an exception. I don't have to check anything in the function, the runtime does for me. More importantly, it throws at the exact point where a null gets converted to a can't-be-null, when taking a List? (or List with nullable disabled), any point in my function using this object can throw and depending on how the code is written, the crash stack trace may or may not end up a gordian knot to debug. With nullable, the stack trace is clear.
-
I'd have thought it was more annoying that .NET 5 is only supported until May: Microsoft .NET and .NET Core - Microsoft Lifecycle | Microsoft Docs[^] The current "long-term support" version is .NET 6, which is supported until ... November 2024[^]. Turns out not having to rewrite everything every three years is yet another bonus to sticking with .NET Framework 4.8.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
What is truly annoying about .NET 5 only supported until May is that projects targeting .NET 6 are not supported in VS2019, so not only do you have to upgrade projects to .NET 6 you have to upgrade environments to VS2022 to work with those projects.
