Runtime: Annotate remainder of .NET Core assemblies for nullable reference types

Created on 2 Sep 2020  路  6Comments  路  Source: dotnet/runtime

Across .NET Core 3.0 and .NET 5.0, we annotated 94% of the netcoreapp assemblies for nullable reference types. In .NET 6.0, we plan to annotate the remaining 6% of that surface area and continue through other assemblies built from the dotnet/runtime repo.

This issue represents the assemblies previously tracked in #2339 that did not get completed in .NET 5.0. Following the same practices we used in .NET 5.0, we will:

  • Submit individual PRs, one for each assembly. Each PR should include changes to both the src and the ref. Each PR should contain only changes related to the nullable annotations/attributes, no other changes.
  • PRs can be merged once the annotations have been appropriately reviewed in PR.

In .NET 5.0, as was tracked in #2339, we completed groups 1-8, most of group 9, all of group 10, and some items in groups 11 and 12

Group 9

  • [ ] System.ComponentModel.TypeConverter (in progress by @safern)
  • [ ] Finish System.Data.Common (i.e. APIs depending on TypeConverter)

Group 11 (not part of netcoreapp but reference netcoreapp)

  • [ ] System.DirectoryServices
  • [ ] System.Diagnostics.EventLog
  • [ ] System.DirectoryServices.Protocols
  • [ ] System.Security.Permissions
  • [ ] System.Windows.Extensions

Group 12 (built from dotnet/runtime but not in netcoreapp and reference netstandard)

With netstandard not annotated, we will need to be cognizant of the fact that all dependencies will be viewed as oblivious:

  • [ ] System.CodeDom => netstandard
  • [ ] System.ComponentModel.Composition.Registration => netstandard, System.Reflection.Context
  • [ ] System.Composition.AttributedModel => netstandard
  • [ ] System.Composition.Convention => netstandard, System.Composition.AttributedModel
  • [ ] System.Composition.Hosting => netstandard, System.Composition.Runtime
  • [ ] System.Composition.Runtime => netstandard
  • [ ] System.Composition.TypedParts => netstandard, System.Composition.Runtime, System.Composition.AttributedModel, System.Composition.Hosting
  • [ ] System.Configuration.ConfigurationManager => netstandard, System.Security.Cryptography.ProtectedData
  • [ ] System.Diagnostics.PerformanceCounter => System.Configuration.ConfigurationManager
  • [ ] System.DirectoryServices.AccountManagement => System.Configuration.ConfigurationManager
  • [ ] System.IO.Ports => netstandard
  • [ ] System.Management => System.CodeDom
  • [ ] System.Runtime.Caching => netstandard, System.Configuration.ConfigurationManager
  • [ ] System.Security.Cryptography.Xml => netstandard
  • [ ] System.ServiceModel.Syndication => netstandard

Lastly

  • [ ] Remove #nullable enable from individual files after all dependent projects annotated
area-Meta tracking

Most helpful comment

Do you think we should include the Microsoft.Extensions assemblies in our nullable annotations for 6.0?

I wonder whether the path is smooth enough now (and our guidance up to date?) that community members could help with annotating those. We've had community folks in the past be happy to help with eg dead code and cleaning up analyzer warnings. I know one concern in the past was that it's hard to review/evaluate community PR's for annotations.

All 6 comments

@ericstj Do you think we should include the Microsoft.Extensions assemblies in our nullable annotations for 6.0?

Do you think we should include the Microsoft.Extensions assemblies in our nullable annotations for 6.0?

I wonder whether the path is smooth enough now (and our guidance up to date?) that community members could help with annotating those. We've had community folks in the past be happy to help with eg dead code and cleaning up analyzer warnings. I know one concern in the past was that it's hard to review/evaluate community PR's for annotations.

Good suggestion, @danmosemsft. We'll put some effort into ensuring the guidance is fully up to date. I intend do to some more project planning around this and probably spawn issues for each assembly to annotate, with them all on a project board. When we do that, we can consider which of them could be marked as up-for-grabs.

I'd be happy to pick up one.

I also opened: https://github.com/dotnet/runtime/issues/41724 to keep track of validation.

I'd be happy to pick up one.

@daniel-white items under Group 1 in issue https://github.com/dotnet/runtime/issues/43605 are also up for grabs once the guidance is up to date for community contributions as explained above by @jeffhandley and @danmosemsft

Was this page helpful?
0 / 5 - 0 ratings