To get a trial key
fill out the form below
Team license
Enterprise license
** By clicking this button you agree to our Privacy Policy statement

Request our prices
New License
License Renewal
--Select currency--
USD
EUR
* By clicking this button you agree to our Privacy Policy statement

Free PVS-Studio license for Microsoft MVP specialists
** By clicking this button you agree to our Privacy Policy statement

To get the licence for your open-source project, please fill out this form
** By clicking this button you agree to our Privacy Policy statement

I am interested to try it on the platforms:
** By clicking this button you agree to our Privacy Policy statement

Message submitted.

Your message has been sent. We will email you at


If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

>
>
>
Do you plan to take on .NET MAUI? Get r…

Do you plan to take on .NET MAUI? Get ready for an adventure with NullReferenceException

Oct 06 2022

.NET Multi-platform App UI is a framework written by professionals. However, the code of some of its functions looks like the developers could have forgotten what null reference dereferencing could lead to.

0996_NRE_MAUI/image1.png

A brief introduction

I can't judge the overall quality of the MAUI project, but I suspect developers will spend quite a bit of time addressing all user reports about unexpected NullReferenceException.

The authors may have been in a hurry to write the code. As a result, some code fragments contain references, which, according to the developers, may be null, and which are not checked for null before dereferencing. To make it clearer, let's take a look at some fragments from the MAUI 6.0.424 source code.

Why so?

When I looked at the fragments I'm listing below, I asked myself the same question. Either I'm missing something, or MAUI developers write very strange code.

Let's take a look at the fragment from the AttachEvents function of the AdaptiveTrigger class:

void AttachEvents()
{
  ....

  _visualElement = VisualState?.VisualStateGroup?.VisualElement;
  if (_visualElement is not null)
    _visualElement.PropertyChanged += OnVisualElementPropertyChanged;

  _window = _visualElement.Window;  // <=
  ....
}

It doesn't make any sense. Judging by the two "?." and the "is not null" check, we may expect null in the _visualElement field. Then the code accesses the Window property, but without first checking _visualElement for null. Apparently, someone overlooked it.

Okay, let's move on. Take a look at the fragment from the FormattedString class:

void OnCollectionChanged(....)
{
  ....
    foreach (object item in e.OldItems)
    {
      var bo = item as Span;
      bo.Parent = null;                   // <=
      if (bo != null)
      {
        ....
      }
  .... 
}

The adjacent lines again. First the developers dereferenced bo, and then suddenly decided to check it for null. I'm not sure whether this code crashes in some cases, but it all looks strange.

Here is a snippet from the ListView class:

protected override void SetupContent(Cell content, int index)
{
  ....

  if (content != null)
    _logicalChildren.Add(content);

  content.Parent = this;
  VisualDiagnostics.OnChildAdded(this, content);
}

It's all nonsense again. Why do they perform a null check only when adding an element to the collection, but skip the check when accessing the property?

I found another "useful" null check in the constructor of the ShellChromeGallery class:

AppShell AppShell => Application.Current.MainPage as AppShell;

public ShellChromeGallery()
{
  ....

  if (AppShell != null)
  {
    flyoutBehavior.SelectedIndex = ....;
    flyoutHeaderBehavior.SelectedIndex = ....;
  }
  else
  {
    flyoutBehavior.SelectedIndex = 1;
    flyoutHeaderBehavior.SelectedIndex = 0;
  }

  AppShell.FlyoutBackdrop = SolidColorBrush.Pink;  // <=
}

Here we go again: we check for null, set some default values if necessary, and then crash immediately.

Considering how often I encountered strange fragments, I even began to think that checking for null was not what it seemed. Take, for example, Unity: the "==" operator is overloaded and the null check works there in a peculiar way intentionally. However, I didn't see anything like that in MAUI.

Why is it so anyway?

MAUI is written by professionals, but the project is very big and complex. People make mistakes, and that's okay. The strange thing is, the project contains such problems despite the fact that various automated tools can catch them. It's not hard to guess that I used the PVS-Studio static analyzer for C# to find these fragments. In my opinion, such tools would simplify the life of MAUI developers. In any case, I wish them success with the development of the project.

Comments (0)

Next comments
Unicorn with delicious cookie
Our website uses cookies to enhance your browsing experience.
Accept