Effective C # Principle 30: Choosing a CLS-compliant assembly

. The NET runtime environment is language-Independent: developers can write components in different. NET languages. And this is often the case in actual development. The assembly you create must be compatible with the common Language System (CLS) in order to ensure that other developers can use your components in other languages.

CLS compatibility is at least close to interoperability with the public name. The CLS specification is a minimal subset of operations that all languages must support. Creating a CLS-compliant assembly means that the public interface of the assembly you create must be limited by the CLS specification. This component can be used by any other language that satisfies the CLS specification. However, this is not to say that your entire program is compatible with the CLS's C # language subset.

In order to create a CLS-compliant assembly, you must comply with two rules: first, therefore the parameters and the values returned from both public and protected members must be CLS-compliant. Second, other public or protected members that are not CLS-compliant must have CLS-compliant consent objects.

The first rule is easy to implement: You can have the compiler to force the completion. Add a CLSCompliant attribute to the assembly on the line:

[ assembly: CLSCompliant( true ) ]

The compiler forces the entire assembly to be CLS-compliant. If you write a public method or attribute that uses a structure that is incompatible with the CLS, then the compiler thinks it is wrong. This is great because it makes CLS-compliant a simple task. After you turn on CLS compatibility, the following two definitions will not be compiled because the unsigned integer is not CLS-compliant:

// Not CLS Compliant, returns unsigned int:
public UInt32 Foo( )
{
　return _foo;
}
// Not CLS compliant, parameter is an unsigned int.
public void Foo2( UInt32 parm )
{
}

Remember that when you create a CLS-compliant assembly, you are only valid for content that can be accessed outside the current assembly. Foo and Foo2, when defined as public or protected, have an error because they are incompatible with the CSL. However, if Foo and Foo2 are internal, or private, they are not included in the CLS-compliant assembly; The CLS-compliant interface is only necessary if the content is exposed externally.

So what happens to attributes? Are they compatible with the CLS?

public MyClass TheProperty
{
　get { return _myClassVar; }
　set { _myClassVar = value; }
}

Depending on the situation, this property is CLS-compliant if the MyClass is CLS-compliant and indicates that it is CLS-compliant. Conversely, if MyClass is not marked as CLS-compliant, then the property is also incompatible with the CLS. means that the previous Theproperty property is CLS-compliant only if the MyClass is in a CLS-compliant assembly.

If your public or protected interface is incompatible with the CLS, then you cannot compile into a CLS-compliant assembly. As a designer of a component, if you do not mark an assembly as CLS-compliant, it is difficult for your users to create a CLS-compliant assembly. They must hide your type and then encapsulate it in CLS-compliant. Sure, this completes the task, but is not a good way for programmers who use components. It's best if you try to do all the work and make the program CLS-compliant: This is the easiest way for users to say that they can make their programs compatible with the CLS.