2

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?

HostileFork says dont trust SE
  • 32,904
  • 11
  • 98
  • 167
David Schmitt
  • 58,259
  • 26
  • 121
  • 165
  • 1
    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? – Hosam Aly Feb 12 '09 at 09:10
  • 1
    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"? – Dave Van den Eynde Feb 12 '09 at 10:07
  • 1
    @Hosam Aly: e.g. not relying on case to differentiate members is good practice regardless of porting or usage. – David Schmitt Feb 12 '09 at 10:35
  • @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. – Jason S Sep 09 '11 at 01:56

3 Answers3

5

"[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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Jason Short
  • 5,205
  • 1
  • 28
  • 45
  • 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)... – supercat Nov 14 '12 at 18:21
  • ...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. – supercat Nov 14 '12 at 18:22
4

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

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
thinkbeforecoding
  • 6,668
  • 1
  • 29
  • 31