Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I hope this is the appropriate forum to ask this question.

A group of colleagues and I just starting learning C# a few weeks ago and we are planning on having a discussion about language interoperability.

So, I am looking for known/classical examples of .Net language interoperability issues. Like this one, where the case-insensitiveness of VB.Net makes an overloaded C# method incompatible.

In C#

public class Foo
    public void foo() { }
    public void fOO() { }

In VB.Net

Public Class Bar
   Sub Bar()
      Dim foo As Foo
      foo = New Foo(); //compiler error
   End Sub
End Class

Or this one in which a VB.Net keyword is used in a C# method name:

In C#

public class Foo
   public virtual void Stop() { }

In VB.Net

Public Class Bar
    Inherits Foo

    Public Overrides Sub Stop() 'compiler error
    End Sub

End Class

I would love to gather a few more examples of this type of issues.

Does anyone know any other interesting cases of language interoperability gotchas?

I used C# and VB.Net in these examples, but any .Net language interoperability issue will be just as good to enrich a discussion on the subject.

share|improve this question

closed as not constructive by Jim G., Glenn Nelson, GlenH7, Frank Shearar, MichaelT Feb 12 '13 at 15:37

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

is it the same post? -… – Yusubov Jul 27 '12 at 17:03
@ElYusubov Yes, in Stackoverflow it was suggested to me that this question should belong in this forum, and not in SO. I waited till it was closed to reopen it here. Is there a reason why it should not belong here? – edalorzo Jul 27 '12 at 17:07
OK, no problem. juts wanted to verify. Thx! – Yusubov Jul 27 '12 at 17:15
I'd just like to point out that the second example you posted can easily be handled by placing brackets around the keyword, like so: Public Overrides Sub [Stop]() – rossipedia Jul 27 '12 at 17:34
Technically, yes. But then again these are the kinds problems that are unavoidable whenever you are crossing the language boundary. – rossipedia Jul 28 '12 at 20:13
up vote 12 down vote accepted

Common Language Specification is a key

It would be better to enhance your understanding of how to write a Common Language Specification (CLS) compliant code. I believe that would resolve most of the issues that you have faced or found.

Basically, CLS compliance refers to CLS rules and restrictions that being followed. However, the concept has a more specific meaning depending on whether you are describing CLS-compliant code or CLS-compliant development tools, such as a compiler. CLS-compliant tools can help you write CLS-compliant code.

enter image description here

There are numerous articles on MSDN and elsewhere that I would suggest to follow:

share|improve this answer
IIRC FxCop has rules to help here – jk. Jul 27 '12 at 17:56

Keep in mind that you are not restricted in the code that is internal to your assembly, only things that are exposed publicly need to be CLS compliant.

  • Don't expose unsigned variables.
  • Don't expose identifiers that only differ by case.
  • Operator overloading, some languages can't use overloaded operators, so provide a method to achieve the same function as your overloaded operator.
  • Avoid unmanaged pointers.
  • Keep names unique, for example don't name a types method and field the same thing.
  • Don't expose boxed value types.
  • Don't overload fields or events.
  • Don't overload properties by type.
  • Don't overload methods by return type.
  • Expose alternative methods for implicit and explicit casts.
  • Don't expose variable length argument lists (params keyword in C#).
  • Don't use arrays with a nonzero lower bound (
  • Don't throw objects that don't inherit from System.Exception.
  • Mark your assembly with (System.ClsCompliant) attribute.
share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.