> Both the .NET Framework and Rotor C# implementations do allow > compile-time enforcement via use of the CLSCompliant attribute. > Using this attribute causes the compiler to error on anything > that it catches as non-CLS compliant, UInt32 etc.
This is one of the advantages IMO of C# over VB.NET, since the C# compiler is proactive in checking developers' assertions re: CLS compliance and erroring if they got it wrong, while the VB.NET compiler is more, ahem, trusting... > I don't think there's any reason for us to desire to underplay > the CLS, it's a useful and important concept. It's in everyone's > interest to encourage language implementors to support this > subset of the CLI at a minimum and compiler implementors to help > developers by having compile-time enforcement. +1. I'd also add that class designers should be encouraged to support exposing all their functionality through CLS-compliant APIs. I've long held [1] that CLS compliance is too important a thing to be left up to the compiler implementor. It would be great to see a stand-alone CLS compliance checking tool that could be used to verify CLS compliance of an assembly. This would let developers catch errors that slip through laxer compilers that don't perform the checks, and would let class library consumers quickly determine if the libraries they are consuming are completely CLS compliant. Monash University has a web service that does this [2]. However, what I'm after is a standalone command-line tool a-la PEVerify, included in the FW SDK, and also ideally implemented as a set of FxCop rules for inclusion in automated build procedures. --Peter http://www.razorsoft.net/weblog http://staff.develop.com/peterd [1] http://www.razorsoft.net/weblog/2002/02/24.html#a32 [2] http://lightning.csse.monash.edu.au/cli-c/