Tue, May 3, 2005, 02:02 PM under
Whidbey |
VisualStudio
VB Class Library projects are marked at the assembly level with
CLSCompliant (while in C# you have to add it yourself). The most important reason for turning it on in your C# library projects is so that you don't accidentally expose case sensitive *publics*; not only this is not CLS compliant, but it would render your assembly unusable by VB code.
So, while it is bizarre that the option is not turned on for C# by default and it is for VB, it makes no difference because it has no effect for VB projects! The situation changes with Whidbey, where suddenly it works as expected. I guess it got noticed when VB got support for unsigned types (also not CLS compliant).
How did I find out? Some of my assemblies are exposed to VB6 clients, so I have public interfaces starting with an underscore (representing the default interface) and other starting with double underscore (representing the default events interface). When I upgraded them to VS2005 B2, I got a whole bunch of CLS compliancy errors (no public types may start with _).
BTW, my solution was to mark them as CLSCompliant(false) rather than tweak the public interfaces and then have to modify all clients too.FYI, with Whidbey, the C# team persists with their choice of not marking the C# projects with the CLSCompliant attribute by default... is that arrogance?