Type of parameter '<parametername>' is not CLS-compliant
A procedure is marked as <CLSCompliant(True)> but declares a parameter with a type that is marked as <CLSCompliant(False)>, is not marked, or does not qualify because it is a noncompliant type.
For a procedure to be compliant with the Language Independence and Language-Independent Components (CLS), it must use only CLS-compliant types. This applies to the types of the parameters, the return type, and the types of all its local variables.
The following Visual Basic data types are not CLS-compliant:
When you apply the CLSCompliantAttribute to a programming element, you set the attribute's isCompliant parameter to either True or False to indicate compliance or noncompliance. There is no default for this parameter, and you must supply a value.
If you do not apply the CLSCompliantAttribute to an element, it is considered to be noncompliant.
By default, this message is a warning. For information on hiding warnings or treating warnings as errors, see Configuring Warnings in Visual Basic.
Error ID: BC40028
To correct this error
If the procedure must take a parameter of this particular type, remove the CLSCompliantAttribute. The procedure cannot be CLS-compliant.
If the procedure must be CLS-compliant, change the type of this parameter to the closest CLS-compliant type. For example, in place of UInteger you might be able to use Integer if you do not need the value range above 2,147,483,647. If you do need the extended range, you can replace UInteger with Long.
If you are interfacing with Automation or COM objects, keep in mind that some types have different data widths than in the .NET Framework. For example, int is often 16 bits in other environments. If you are accepting a 16-bit integer from such a component, declare it as Short instead of Integer in your managed Visual Basic code.