Guidance on whether to indicate CLS compliance

[Eilon]

Can/should we have guidance on whether to indicate CLS compliance? It comes up from customers/community every so often, but in my view the cases for it tend to be weak because they are based on hypothetical cases, or circular logic.

For example:

1. What if some obscure language is used?

• I think it'll probably work just fine anyway, as long as you're not actually doing anything that isn't CLS complient

2. But I want to mark my own assembly as CLS compliant and I can't because it depends on XYZ, which isn't

• This goes back to (1) and whether there's any point to it at all these days in modern libraries

I think it would be good to have explicit guidance on this that we can point people to.

cc @KathleenDollard @richlander @terrajobst @DamianEdwards

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: e80fe2fd-cbdb-699e-0dbb-a0a310bd372c
• Version Independent ID: 266d08ae-344a-683b-11e2-143b704e21a8
• Content: Open-source library guidance
• Content Source: docs/standard/library-guidance/index.md
• Product: dotnet
• GitHub Login: @JamesNK
• Microsoft Alias: mairaw

[JamesNK]

Agreed. Right now the guidance focuses on higher level topics like cross-platform and packaging. There is an opportunity to have one or more articles on the API design. For example:

• Discussing CLS
• Recommending Framework Design Guidelines
• Highlight recommended extension points for logging, configuration, ASP.NET, Azure, etc
• Providing testable libraries

[mairaw]

@JamesNK should this be moved to our backlog?

[JamesNK]

I don't know what the right answer is. It would require some investigation.

Sure, backlog is fine.