Target the Common Language Specification (CLS) when you want a .NET library’s public API to be usable from any .NET language that supports the CLS. It is an interoperability design choice for the API your consumers see—not a requirement that every library follow, and not a restriction on private implementation details.
What CLS compliance means for a library
The CLS is a subset of .NET features intended to let language-independent components work across languages that support that subset. A library designed to be CLS-compliant exposes public features that CLS-supporting languages can use. That does not mean every language supports every feature available on .NET.
Microsoft states: “The rules for CLS compliance apply only to a component’s public interface, not to its private implementation.” Microsoft Learn’s language-independence guidance explains the scope and purpose of the rules.
When to make your library CLS-compliant
Choose compliance for a broad or cross-language audience
Mark the library as CLS-compliant when you want its public API to be consumable from a broad range of CLS-supporting .NET languages, or when cross-language use is an explicit compatibility goal. Compliance makes that intent visible and gives compiler tooling a basis for flagging public signatures that fall outside the CLS.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
#1 Best Overall
Consider a narrower API when the audience is known
If your library targets a known set of consumers and a non-CLS feature materially improves its API, you can choose to expose that feature. Be clear that the exception narrows cross-language accessibility. Where practical, provide a compliant alternative so consumers using other CLS-supporting languages are not shut out of the relevant capability.
How to declare and check compliance
-
Declare assembly intent. Add
[assembly: CLSCompliant(true)]to mark the assembly as CLS-compliant. -
Review exposed signatures. Check the public API for types and members that do not follow CLS rules. Private implementation details do not need to comply solely for this purpose.
-
Mark deliberate exceptions. If a public type or member is intentionally noncompliant, mark it with
[CLSCompliant(false)]and document the exception.Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
Offer alternatives where feasible. Provide a CLS-compliant type or member with equivalent utility when practical, and explain how it relates to the exception.
-
Address compiler warnings. Treat warnings about exposed noncompliant signatures as API-design signals: either change the signature or explicitly identify the exception.
Rank #4
The CLSCompliantAttribute API reference describes where the attribute can be applied and how its value is inherited by contained elements. An explicit setting can be overridden for an exposed exception. Although the attribute usage permits targets such as parameters, generic parameters, and return values, Microsoft says applications to those targets are ignored in practice; mark the containing member instead.
Microsoft’s CA1014 code-analysis guidance says, “Good design dictates that all assemblies explicitly indicate CLS compliance with CLSCompliantAttribute.” This is a design recommendation grounded in cross-language intent, not a claim that every library is universally required to comply. See CA1014: Mark assemblies with CLSCompliantAttribute.
How to choose between a compliant API and an exception
| Consideration | Design for CLS compliance | Expose a non-CLS feature |
|---|---|---|
| Audience | Useful when broad cross-language use is a goal. | May fit when the intended consumer set is known and narrower. |
| API expressiveness | Favors the common feature set recognized by CLS-supporting languages. | Can preserve a feature that materially improves the API for its intended users. |
| Access for other languages | Supports access through the compliant public surface. | Can reduce access; a compliant alternative may preserve access to the capability. |
| Maintenance and clarity | Requires reviewing exposed signatures for CLS rules. | Requires clearly marking and documenting exceptions and keeping alternatives consistent. |
A public API containing a non-CLS type or signature should not be presented as wholly CLS-compliant without clearly identifying the exception. Conversely, there is no need to constrain private implementation just to claim CLS compliance.
What the declaration does—and does not—guarantee
CLSCompliantAttribute declares intent and helps support checking; it does not make an incompatible signature usable from every language. Compiler warnings can identify public signatures presumed compliant when they are not, and individual compilers may enforce some CLS rules even when the attribute is absent. The attribute and checks do not remove the need to review the API against the languages and consumers you intend to support.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
