When is it acceptable to break CLS compliance?

Question

I was wondering which edge cases exist that could make Common Language Specification compliance acceptable. Even when not intending to be accessed from other languages, I think that the tenets asserted by the CLSCompliantAttribute are good best practices.

Do you have encountered / know of cases where YAGNI outweighs the best practices?

Answer 1

"[sic] What use is there for being CLS compliant?"

Medium trust, ClickOnce, running from a shared network drive, guest profiles in a domain setting, etc. There are lots of security situations where your code cannot run if you break the CLS Compliance.

I have personally seen a lot of situations where users are trying to run their application from a shared network drive and can't because the local admin has killed non-CLS compliant applications in the security profile.

In general, there are usually ways to work around the issue anyway. I would take the opposite approach to the comments above, why break it? You are writing managed code, why would you want to limit your application on purpose?

I would say that if you are building an API assembly or component, you should always adhere to them. Too many third-party components take the easy way out and just flag them as broken when attempting to run from medium trust. In some cases, this is the only reason they can't run. If they had taken a little more time to adhere to the guidelines, users would not be limited as to how they can use their component.

Answer 2

Well, "params" arrays on attributes are sometimes just so tempting (but non-compliant). But I'd recommend using CLS-compliant approaches whenever possible.

Answer 3

I think it's acceptable for library internal to a product when working with legacy layers that require that kind of features or for performance reasons.

But these non-conformant interfaces should then be reencapsulated at a higher level.