As you know Microsoft .NET is designed for cross-language interoperability. In other words, two .NET compliant languages can interoperate with each other. This simply means a function in VB .NET can be called by C# and vice-versa.
Let's understand this practice, and consider a scenario where a C# Class Library (.dll) is being used by the VB .NET client (.exe).
Create a C# Class Library project
- If not already, promote the Class1 to be public.
- Create functions as shown in figure 1-1 below.
- Compile the code, to have a .dll successfully produced in the bin\debug folder.
Figure 1-1 C# Class Library having a similar function in different cases (upper and lower cases)
In this example, I have declared three functions that differ in the cases of the letters used to form the name of the function, In other words, Sum, sUm, and SUM, this is possible considering we are working with a case in the sensitive language of choice, C#.
Now, let's try to consume this C# create .dll in a VB .NET client application.
- Create a VB .NET Console Application.
- Add Reference to ClassLibrary.dll that we created in C#
- Add Imports ClassLibrary.Class1 on the VB .NET code file, as shown in the image below.
- Create an object of class library
Dim obj As New ClassLibrary.Class1
Figure 1-2 VB .NET Console application consuming C# Class library
But I don't see my C# functions in VB .NET, is there a problem?
Figure 1-2, doesn't show our C# functions Sum, sUm, and SUM that we created shown in Figure 1-1. There is a problem, and that is a genuine issue. Let's understand this.
If you observe the C# is fully capable of declaring functions that differ only by case, VB .NET is completely incapable of recognizing this case difference (due to its case in-sensitivity). This is the reason that we don't see those C# functions in VB .NET.
I got the problem, now what is the fix?
The fix for this problem is to follow the Common Language Specification (CLS), and CLS needs to be followed by a language that another language won't be able to recognize and understand.
For example, class members that differ in the case and UInt, etc. are not considered CLS Compliant. Let's enforce the CLS compliance in C#, so it's case sensitive nature can't be misused in order to break interoperability with clients like VB .NET or similar .NET compliant language(s).
To fix this, we need to make a C# assembly CLS complaint, as in:
- Go to C# Class Library project
- Open Class1.cs
- On the top of namespace ClassLibrary, add the statement
[assembly:CLSCompliant(true)]
Figure 1-3 making the assemble CLS Complaint
Once you have made the change as suggested above and in Figure 1-3, build the class library and you should observe the Warnings list in the Error List window. If the Error List window doesn't show up then make sure you open it via "View" -> "Error List".
When you open the Error List, you will notice the warnings as shown in Figure 1-4 below.
Figure 1-4 Error List with warnings confirming NON - CLS Compliance
Now, as you will see this code is now complaining about not being CLS Compliant, since we have two functions that differ only in case. So to get rid of these warnings, either we must change the function names or remove these from the class library.
Let's try changing the name for these two functions to Sum2 and sUm3 as shown in Figure 1-5 below.
Figure 1-5 renamed functions to confirm the CLSComplaince
Let's re-test this with VB .NET
We already have VB .NET code, as shown in Figure 1-2 above where we didn't have access to functions we created. But now you will be able to access all your functions as you have met the CLS Compliance in C#. This is tricky, as you might think that is this a real fix? Actually, there is no way you can access those case sensitive functions in VB .NET at all, no matter what.
Hence, we have standards to be enforced if needed. This puts a restriction on C# and suggests that you are CLS Compliant and so be careful when declaring class members that differ only in case or try to use something that is only used by C# for example UInt16 that is not used by many other languages e.g. VB .NET.
Figure 1-6 VB .NET showing access to C# functions after CLS Compliance of a C# assembly.
Figure 1-2 VB .NET Console application consuming C# Class library
Anupam SinghPosted Jun 3, 2014, 1:55 AM
Nice article sir... very useful.
Praveen Raveendran PillaiPosted Jun 3, 2014, 12:47 AM
Nice article..Thanks for sharing..!!!
Vinod NairPosted Oct 9, 2013, 12:59 AM
Really great article Thanks
Naga SankarPosted Sep 10, 2013, 12:34 PM
Very nice article sir
Sam HobbsPosted May 12, 2013, 10:31 AM
Using unmanaged code, a single exe or single DLL can have code compiled from more than one language by statically linking the object files (the output of the compilers) together. So I could write a C++ program that calls code developed using COBOL, Pascal and/or Assembler. They could all be mixed together. Microsoft Visual Basic never worked like that but there are other Basic compilers that would. Using managed code, only one language can be used for each exe or DLL.
Vidya Vrat AgarwalPosted Apr 30, 2013, 5:49 PM
@Sam Hobbs, I am not very clear with your question. Are you asking, 1- If an exe can call code from C# class or dll and VB .NET class or dll? OR 2- Single dll can contain source code in C# and VB .NET language. Answer is - 1-Yes, 2- No
Sam HobbsPosted Apr 16, 2013, 6:04 PM
Is there a way that managed code can call programs written using a different language directly; in other words, if they are all in the same exe or the same DLL? Unmanaged code can do that but I see no way to do it using managed code. Therefore I think that managed code reduces cross-language interoperability in some significant ways.