Background

As far as I know, CLS was from the early versions of CLI standard, to mark members that "may not be supported by compilers that only supports the minimal set". Nowadays, it's causing confusion among the .NET ecosystem.

Current pains

False negative (marked with [CLSCompliant(false)], but widely supported)

The most common non-CLS-complaint feature should be unsigned integers. Nowadays, all the three major alive languages (C#, VB, F#) support unsigned integers. Continuously marking them with [CLSCompliant(false)] is meaningless work at the sight of major consumers.

False positive (marked with [CLSCompliant(true)], but requires certain compiler to support)

As the runtime evolving, it introduces new features that's not defined in early versions of standards. The most famous one should be Span<T> and ref structs. Howover, Span<T> is not marked with [CLSCompliant(false)], but with modreq. This makes CLSCompiaint a rigid mark that doesn't even fit older standard.

Analyzer about "mark assembly with [CLSCompliant]" (CA1014) confuses developers

Although the BCL may still mark with [CLSCompliant] for standard conformant, library and application developers typically won't want to be bothered by it, because it means nothing in realistic.

As .NET 5 bringing NetAnalyzers inbox, it's bothering in more ways. Some developers (for example me) choose to enable AnalysisMode = AllEnabledByDefault for more strict analysis, and that brings CA1014.

There are certain legacy analyzers shipped with NetAnalyzers, but not included in AllEnabledByDefault (CA1021, CA1045). I think CA1014 may be included in it.

Proposed actions

• Remove CA1014 from AnalysisLevel_5_AllEnabledByDefault.editorconfig, as it's not meaningful for .NET 5 applications, and not easy to turn off(CA1014 can't be turned off in editorconfig roslyn-analyzers#4400)
• Reconsider what to do with old CLS compliance in BCL
• If you decide to keep [CLSComplaint], consider the chance of marking Span and related apis with [CLSCompliant(false)].