As part of C# 8.0, we have access to a Nullable Reference Types (NRT) feature. This allows the have a more explicit flow of nulls in the codebase.
The NRT feature holds you to a higher standard on how you deal with nulls, and as such it issues new warnings on existing code. So that those warnings (however useful) don’t break you, the feature must be explicitly enabled in your code before it starts complaining. Once you do that on existing code, you have work to do to make that code null-safe and satisfy the compiler that you did.
This might bring some potential breaking changes for the providers and customers that consume our library. I think this should be released with a breaking change alert.
### Tasks
- [x] Add nullable enable to the common.props
- [x] Fix the warnings related to nulls that arise from it
- [x] Review all public API surfaces
Requirements
As part of C# 8.0, we have access to a Nullable Reference Types (NRT) feature. This allows the have a more explicit flow of nulls in the codebase.
Check: https://devblogs.microsoft.com/dotnet/embracing-nullable-reference-types/
Possible breaking changes
This might bring some potential breaking changes for the providers and customers that consume our library. I think this should be released with a breaking change alert.
Notes
To ease the migration, the new code created can use a preprocessor directive. See https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/preprocessor-directives#nullable-context
Potential tasks