Can an assembly that includes a non-CLS-compliant reference be CLS-compliant?

Question

I have an existing DLL that is not CLS-compliant that I reference from my own project. When I mark my assembly as CLS-compliant, I get compiler warnings that names in the referenced assembly are not CLS-compliant.

Is there a way I can keep my assembly CLS-compliant and mark the referenced one as not?

Mawkish

Answer 1

Yes, your DLL can be CLS-compliant as long as it doesn't expose any non-CLS-compliant members from the referenced assembly -- that is, it doesn't mention them in any of its own public or protected members or types. (It can still use them in private and internal members and types.)

If your DLL does need to expose types directly from the non-compliant DLL, you can either try encapsulating those types in your own wrappers (e.g. a method might return a MyWrapperAroundNaughtyType instead of a NaughtyType), or you can mark the relevant members of your API CLSCompliant(false) to opt just those members out of compiler checking.

Terrorize

Do I also need to mark "Embed Interop Types" as false? (It's a COM library that's not CLS-compliant due to names with underscores.) – Mawkish

I am not sure. Since the interop types you'd be using are public, they'd be embedded as public, which means they'd be checked for CLS-compliance. But when I did a quick experiment it seemed to go okay -- but perhaps I just got lucky with my COM types. Perhaps try creating a small dummy assembly that imports the problem COM types and try it on that before embarking on it with your real assembly? – Terrorize

I just tried it with Microsoft.Office.Interop.Excel and get warnings if I include it in a using statement anywhere. It seems like either marking my assembly as non-compliant or not embedding the interop types is the way to go. Or I could fully qualify all class names... nah. – Mawkish

if you wrap around the naughty type, aren't you still exposing it with your wrapper? – Lemonade

Not as long as you keep any mentions of the naughty type private or internal within the wrapper. – Terrorize

Answer 2

What I ended up doing because the other suggestions didn't work was setting the property Embed Interop Types of the referenced dll (with the non-CLS-compliant members) to false.

Bonnice