Language Interoperability C# Help

The use of IL not only enables platform independence; it also facilitates language interoperabilitv, Simply put, you can compile to IL from one language, and this compiled code should then be interoperable with code that has been compiled to IL from another language.
You are probably now wondering which languages aside from C# are interoperable with .NET,the following sections briefly discuss how some of the other common languages fit into .NET.

Visual Basic 2008

Visual Basic .NET 2002 underwent a complete revamp from Visual Basic 6 tv bring it up to date With the first version of the .NET Framework. The Visual Basic language itself had dramatically evolved from v86, and this meant that VB6 was not a suitable language for running .NET programs. For example, VB6
is heavily integrated into Component Object Model (COM) and works by exposing only event handlers as source code to the developer – most of the background code is not available as source code. Not only that, it does not support implementation inheritance, and the standard data types that Visual Basic6 uses are incompatible with .NET.  Visual Basic6 was upgraded to Visual Basic .NET in 2002,and the changes that were made to the language are so extensive you might as well regard Visual Basic as a new language. Existing Visual Basic6 code does not compile to the present Visual Basic 2008 code (or to Visual Basic .NET2002,2003, and 2005 for that matter). Converting a Visual Basic 6 program to Visual Basic 2008 requires extensive
canges to the code. However, Visual Studio 2008 (the upgrade. of Visual Studio for use with .NET)can
most of the changes for you. If you attempt to read a Visual Basic 6 project into Visual Studio 2008, it will upgrade the project for you, which means that it will rewrite the Visual Basic6 seurce code into
ual Basic2008source code. Although this means that the work involved for you is heavily cut down,you will need to check through the new Visual Basic 2008code to make sure that the project still works as intended because the conversion might not be perfect.

One side effect of this language upgrade is that it is no longer possible to compile Visual Basic 2008 to native executable code. Visual Basic2008 compiles only to IL,just as C# does. If you need to continue coding in Visual Basic6, you can do so, but the executable code produced will completely ignore the .NET Framework, and you will need to keep Visual Studio 6 installed if you want to continue to work in this developer environment.

Visual C++ 2008

Visual C++ 6 already had a large number of Microsoft-specific extensions on Windows. With Visual C++ .NET,extensions have been added to support the .NET Framework. This means that existing C++ source code will continue to compile to native executable code without modification. It also means, however,
that it will run independently of the .NET runtime. If you want your C++ code to run within the .NET Framework, you can simply add the following line to the beginning of your code:

               *using <mscorlib.dll>

You can also pass the flag /clr to the compiler, which then assumes that you want to compile to managed code, and will hence emit IL instead of native machine code. The interesting thing about C++ is
that when you compile to managed code, the compiler can emit IL that contains an embedded native executable. This means that you can mix managed types and unmanaged types in your C++ code. Thus, the managed C++ code,

           class MyClass

               {

               defines a plain C++ class, whereas the code

                             ref class MyClass

                   }

gives you a managed class, just as if you had written the class in C# or Visual Basic2008. The advantage of using managed C++ over C# code is that you can call unmanaged C++ classes from managed C++ code without having to resort to COM interop.

-The compiler raises an error if you attempt to use features that are not supported by .NET on managed types (for example, templates or multiple inheritances of classes). Youwill also find that you will need to ase nonstandard C++ features when using managed classes.

Because of the freedom that C++ allows in terms of low-level pointer manipulation and so on, the C++ compiler is not able to generate code that will pass the CLR’s memory type-safety tests. If it is important that your code be recognized by the CLR as memory type-safe, you will need to write your source code in some other language (such as C# or Visual Basic 2008).

COM and COM+

Technically speaking, COM and COM+ are not technologies targeted at .NET,because components based on them cannot be compiled into IL (although it is possible to do so to some degree using managed C++, if the original COM component was written in C++). However, COM+ remains an important tool, because its features are not duplicated in .NET.Also, COM components will still work and .NET incorporates COM interoperability features that make it possible for managed code to call up COM components and vice versa (this is discussed in Chapter 24, “Interoperability”). In general,
however, you will probably find it more convenient for most purposes to code new components as .NET components, so that you can take advantage of the .NET base classes as well as the other benefits of running as managed code.

Posted on October 27, 2015 in .NET Architecture

Share the Story

Back to Top