Here is some helpful information about CLS-compliancy 

The Common Language Specification (CLS)

Because .NET languages have the infrastructure to interact with each other seamlessly, yet each language many choose to implement its own unique features, Microsoft has established a Common Language Specification that defines a subset of functionality that all .NET languages should support.  (It also defines conventions that should be followed.)  This way, component writers can guarantee that their components will work seamlessly from C#, to VB.Net, COBOL, Perl, Eiffel, or any other .NET language that honors the CLS.  Such a component is said to be CLS-compliant.  CLS restrictions apply only to public types and their public or protected members, parameters, and return types.  Internally, components can do whatever they want and still be considered CLS-compliant.

Examples of features in the CLS (that languages must support) are strings, integers, enumerations, and arrays.  Examples of features not in the CLS are unsigned integers, optional parameters, and pointers.  Thus, you should avoid writing public methods with features such as optional parameters because you cannot count on every language supporting them.  Some compilers (including the VSTA compilers) can optionally check the CLS-compliance of your code, so you don’t have to become familiar with the rules and examine your code manually.  Also, rest assured that most of the API’s that Microsoft exposes in the .NET framework are CLS-compliant.

-excerpted from Adam Nathan’s .NET and COM, p 16