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?

Darrondarrow

If you're building an application that is not going to be used as a library, and you know it won't be ported to other platforms (e.g. Mono), what use is there for being CLS compliant? – Medwin

Relying on case only is a good practice when differentiating between properties and their private backing fields. Or is that an exception to your "rule"? – Prepossessing

@Hosam Aly: e.g. not relying on case to differentiate members is good practice regardless of porting or usage. – Darrondarrow

@Dave Case only differences between public properties and private backing fields is CLS compliant. It is case only differences between public members (or members accessible outside the class) that is not. – Attendant

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.

Creedon

What is the relationship between CLS compliance and trust? I thought non-CLS compliance simply meant that some features of your class might be unusable from some languages; e.g. if a collection only exposed its Count property as a UInt32, code written in a languages that didn't support that type would be unable to find out how many items were in it. If some feature only makes sense in languages which support unsigned types (e.g. calling a UInt32 overload of an Interlocked.Increment-style function would only make sense if one already had such a UInt32 variable to increment)... – Lemures

...I don't see any reason why including such an overload should be considered a "bad" thing, or limit the security contexts where a code could be used. – Lemures

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.

Enedina

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.

Muco

I agree. As long as the library is for internal use and you have control of its usage this should not be a problem. – Reube