CLS Compliance warning CS3016 is reported on non-public members

[dsplaisted]

Compile the following code:

using System;

[assembly:CLSCompliant(true)]

[CLSCompliant(false)]
public sealed class SharingBoundaryAttribute : Attribute
{
    public SharingBoundaryAttribute(params string[] sharingBoundaryNames)
    {
    }
}

class LightweightWebBenchmark
{
    [SharingBoundary("name")]
    public object WebScopeFactory { get; set; }
}

EXPECTED: No warnings
ACTUAL: warning CS3016: Arrays as attribute arguments is not CLS-compliant

If you try to disable the warning by putting [CLSCompliant(false)] on the LightweightWebBenchmark class (or its WebScopeFactory property), you get this error:

warning CS3019: CLS compliance checking will not be performed on 'LightweightWebBenchmark' because it is not visible from outside this assembly

So for code like this it doesn't appear possible to avoid CLS compliance warnings, without disabling CLS compliance for the whole assembly or using specifically ignoring this warning.

[AlekseyTs]

The behavior is consistent with behavior of VS2013 compiler. Moving to 2.0. I am not sure if it is worth changing the behavior at all.

[jaredpar]

So for code like this it doesn't appear possible to avoid CLS compliance warnings, without disabling CLS compliance for the whole assembly or using specifically ignoring this warning.

Have you tried #pragma warning disable?

[jaredpar]

@AlekseyTs if it's consistent with native compiler I agree at least 2.0. However is this a bug or "by design"? If it's a bug I'd like to keep for fixing, if not though I'd like to close it out.

[AlekseyTs]

@jaredpar As far as I know, there is no compiler spec for CLS Compliance that we can refer to. For Roslyn, our goal regarding CLS Compliance was to duplicate native compiler behavior. So, it is everyone's judgement call whether this is by design or a bug. Regardless, in my personal opinion, it is not worth changing the behavior in this area.

CC @amcasey

[amcasey]

As @AlekseyTs said, when we implemented this, we found ourselves in a tight spot - the rules aren't strict enough to ensure that APIs will work across language enough, but strengthening them would have broken existing programs. While I hope that eventually we will be able to implement stronger rules as analyzers, our present goal is to mimic dev12 on a best-effort basis, favoring fewer, rather than more, diagnostics.

[jaredpar]

Given the constraints here I agree with Close / Won't fix. Thanks!