What is the Common Language Specification (CLS), and when should you mark a library as CLSCompliant?

How I would answer this in an interview

The Common Language Specification (CLS) is a subset of the CTS — a set of rules for publicly visible API surface that every CLS-consuming .NET language is guaranteed to support. If a library's public API follows the CLS, any .NET language can call it. [assembly: CLSCompliant(true)] asks the C# compiler to check your public surface against those rules and warn when you break them.

1. Why it exists

.NET was designed for many languages with different capabilities: some are case-insensitive (VB.NET), some lacked unsigned integers, some don't support operator overloading or pointers. The CLS defines a common denominator so that public types and members of a library are consumable everywhere. Internal implementation can use anything.

2. Main CLS rules (for public/protected members)

• No unsigned types in public signatures: uint, ulong, ushort, sbyte (use int, long, short, byte, or provide CLS-compliant alternatives).
• No pointers or function pointers in public signatures.
• Names must not differ only by case (Total and total both public) — case-insensitive languages couldn't distinguish them.
• Identifiers must follow Unicode identifier rules; no leading underscores in some contexts (e.g. public members starting with _ trigger warnings).
• Arrays must have zero-based lower bounds; element types must be CLS-compliant.
• Overloads can't differ only by ref vs out or by unsigned vs signed parameter types.
• Operator overloads should have named method alternatives (op_Addition exists, but languages without operator support need Add) — guidance rather than a hard rule.
• Generic constraints and type parameters must be CLS-compliant; types deriving from non-compliant types are non-compliant.
• Exceptions should derive from System.Exception.
• Attributes used publicly should have CLS-compliant constructor parameter types.

3. How CLSCompliant works

[assembly: CLSCompliant(true)]

public sealed class Checksum
{
    public uint Compute(byte[] data) { ... }          // warning CS3002: return type not CLS-compliant

    [CLSCompliant(false)]
    public uint ComputeRaw(byte[] data) { ... }       // explicitly opted out: no warning
    public long Compute32(byte[] data) => ComputeRaw(data);   // CLS-friendly alternative
}

• The attribute on the assembly turns on checking; individual members/types can opt out with [CLSCompliant(false)].
• The compiler only checks — it doesn't change code generation. Non-compliant code still compiles (warnings CS3001–CS3027).
• Non-public members aren't checked.
• In newer .NET versions, many analysers and templates don't add CLSCompliant by default; the BCL itself is marked CLS-compliant with explicit opt-outs (e.g. UInt32 APIs).

4. When should you mark a library CLSCompliant?

Consider it when:

• You publish a general-purpose public library (NuGet) that may be consumed from VB.NET, F#, PowerShell, or other .NET languages, and you want to guarantee broad usability.
• Your organisation has mixed-language codebases (VB.NET legacy apps calling C# libraries).
• You want a lint for case-only name differences and accidental unsigned types in public APIs.

Usually unnecessary when:

• It's an application or internal library consumed only by C#.
• The library is inherently low-level (interop, binary protocols) where unsigned types are natural — marking it compliant would require many opt-outs.
• Consumers are known (e.g. microservice internals).

In practice, the most valuable parts of the CLS rules are good API design anyway: avoid case-only differences, prefer signed types unless the domain needs unsigned, provide named alternatives to operators.

5. A production example

A C# SDK we published for partners was also used by a partner's VB.NET desktop application. A release added two public properties differing only by case (Url and URL, one marked obsolete) and a method returning ulong. VB.NET consumers got ambiguity errors and couldn't use the method naturally. We added [assembly: CLSCompliant(true)], fixed the case clash, added long-returning alternatives with [CLSCompliant(false)] on the unsigned versions, and included a VB.NET smoke-test project in CI.