|
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, 2013
|
|
|
|
|
|
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
|
|
|
|
|
Open the .csproj file and change "the" line to read:
<Nullable>disable</Nullable>
And yes, bloody annoying.
|
|
|
|
|
No need to edit, that Nullable switch 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.
|
|
|
|
|
#realJSOP wrote: Nanny state bullsh|t...
Yup. The state dictates that, offcourse.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
|
Let me see.
I can enable null check - clearly advertising intent outside my method - make it very clear where I can ignore null check and get the compiler to tell me where I need it. Reference types and value types both able to advertise clearly if they are nullable or not.
Or I can disable nullable check and accept more null reference exceptions - often not telling you enough to easily tell what was null when all you have is a log file from a production server. When calling a method always having to wonder "hmm, can this return null or not" - and either forget to handle null in one or another edge case, or clutter the code with null handling code that will never execute. And have value types that can communicate if they can be null or not, while my reference types can't.
And in case you say "never happens to me". Well, congratulation for working on such a simple code base.
It is not exactly a hard choice for new code. I can't think of a single reason to disable it besides "I am not used to it".
For old code it is of course a question if it is worth the investment which will vary from project to project.
It is unfortunately not as good as it should be due to the requirement to link to libraries developed before null checks, but at least it is an attempt to fix one of the most serious design mistakes in the .NET type system.
Can we please get more "nanny state" to let the compiler deal with this trivial crap so I can concentrate on the domain.
|
|
|
|
|
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.
|
|
|
|
|
Either you misunderstood what I wrote, or I misunderstood you 
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'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
|
|
|
|
|
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. 
"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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
This 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
|
|
|
|
|
I'm seeing .Net 5 as a glorified beta release, where .Net 6 is the release version
|
|
|
|
|
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.
|
|
|
|
|
I have been sticking with .NET 4.6 since that is the framework I have been developing my current project in.
When I started the project, WPF wasn't fully supported in the new .NET frameworks.
No problems at all and I still have access to all that "legacy" technology that disappeared with the new .NET Core Frameworks...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
I typically use .Net 4.7, but in this instance, I was curious about Avalonia and writing a cross-platform app, so I am trying to convert a 10-year-old WPF app to it, and in the process, I chose to use .net 5.0. Avalonia is even more infuriating than .Net5. I went in thinking it was a "better wpf than wpf", but there are a seemingly infinite number of things that it does differently (for instance, instead of having the Visibility attribute, it's IsVisible, which broke a moderate amount of XAML and viewmodels). Many of the same WPF principles apply, but there are enough differences that an experienced WPF dev will be tearing their hair out trying to get it to work.
".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
modified 19-Feb-22 8:00am.
|
|
|
|
|
I understand your pain...
The only thing I am interested with the new .NET Core Frameworks is Blazor Server-Side. It appears to be a return to WebForms with a twist, which I have been predicting for years...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
