Enable nullable reference types in the solution and evaluate code (OSOE-754)

[sarahelsaig]

Enabling nullable mode for the HL would make the code much safer and give us more confidence about where additional null checks are needed or not. It's also painful to implement abstract methods from HL that should be able to return null in a nullable enabled project because the IDE gets confused.

Also the codebase should be reviewed to guarantee that the methods only return null when it has a special meaning (e.g. in drivers) and to consider making the inputs as resilient as possible.

Jira issue

[Piedone]

Duplicate of Lombiq/.NET-Analyzers#48, right?

[sarahelsaig]

No. Some time ago, we discussed that it's okay to enable nullable in new projects even before it's globally enabled via Lombiq.Analyzers. I think it's even more applicable to HL for the reasons I mentioned above and because that reduces the intimidation factor of Lombiq/.NET-Analyzers#48, that will necessarily involve making all of our projects use nullable references first. So this issue could be considered a blocker for it.

[Piedone]

Yeah, good point.

[Piedone]

For this, Lombiq.HelpfulLibraries.Refit needs to be moved to .NET 8 from .NET Standard. This is not an issue, since it was required only for Lombiq.OrchardCoreApiClient, which is now .NET 8 too.

A Directory.Build.props file like this could be placed into the repo roo to enable for all projects:

<Project>
  <PropertyGroup>
    <Nullable>enable</Nullable>
  </PropertyGroup>
</Project>

[Piedone]

This should rather be done after we upgraded to Orchard Core 2.0, to prevent an insane merge conflict.