3

This question is more out of curiosity than a project requirement or a problem.

I have a Non-CLS compliant code in one language (say C#), and I need to use it like that only in my current language (across projects, so making internal is not a choice), and at the same time want to allow other languages (say VB) to be able to call the conflicting implementations without generating compile time error.

For instance,

//C#
public class SecurityService
{
....
    public void Print()
    {
        Console.WriteLine("print"); //This method prints Service Name in lower case
    }

    public void PRINT()
    {
        Console.WriteLine("PRINT");//This method prints service name in UPPER case.
    }
}
'VB.Net 

Module ServiceReader

    Sub Main()
        Dim service As New SecurityService()
        service.print() 'Compile time error: print is ambiguos
    End Sub

End Module

Problem: I need to avoid the compile time error here by somehow hiding one of my 'print' methods from cross language projects (allowing C# projects to call the desired implementation).

Thanks for your interest.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
Manish Basantani
  • 16,931
  • 22
  • 71
  • 103
  • 2
    If you need them both `public`, rename `PRINT` to `PrintUpperCase`. – Jaroslav Jandek Mar 12 '11 at 17:21
  • What would happen if you added a dummy inheritance layer, with `PRINT` being part of the base and `print` being part of the other? I would expect VB.NET to happily use the derived-class version given any upper/lowercase form of "Print", while C# would use the version precisely matching the code, but I've not tried it. – supercat Jan 22 '15 at 17:02

3 Answers3

3

A language like VB.NET offers no escape around its fundamental syntax rule that identifiers are case insensitive. It is not hard to solve, you can simply write a little static adapter method in a case sensitive language like C# that makes the call.

public static class Interop {
    public static void Print2(SecurityService obj) {
        obj.PRINT();
    }
}

You can completely shove it under the doormat by making it an extension method, assuming the language supports it. There will be no actual runtime overhead when the jit optimizer is done with it.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
1

I'd suggest you make the non-CLS compliant methods/properties internal, but then make another class that isn't CLS compliant to call that stuff and mark that class as [CLSCompliant(false)]

Mark Sowul
  • 10,244
  • 1
  • 45
  • 51
  • "CLSCompliant(false)" - does this attribute do anything more than suppressing the compiler warning? – Manish Basantani Mar 13 '11 at 06:21
  • It marks the specific class as being non-CLS compliant. You can even mark a specific method as non-CLS compliant but as your goal is to hide it from cross-language projects, using another class to point to them (e.g. MyClassExtensions) seems the better way. – Mark Sowul Mar 13 '11 at 07:38
1

I don't see the point of trying to make this work. My advice would be to avoid the problem in the first place and stop writing non-compliant code, especially if you are planning on supporting different languages. You have total control over the module here so you shouldn't actually need any fancy hacks.

bobbymcr
  • 23,769
  • 3
  • 56
  • 67