Chapter 1(Part 3)Introduction to Visual Basic

Every constructs (such as class, struct, etc. ) in every .NET languages must compile to CLR compatible types to qualify as .NET managed code. You can choose compilers such as Visual Basic, C#, Visual C++, JScript, or one of many third-party compilers like Eiffel, Perl, or COBOL compiler. CLR supports a wide variety of data types and language features.

It is not mandatory to include all the CLR features in every .NET enabled languages, but the exposed language features should be compatible with the standard .NET frame work.

If your component is targeted to use by components written in other .NET languages, your component’s exported types must expose only language features that are included in the Common Language Specification (CLS).

1.3.3 Microsoft Intermediate Language (MSIL)

MSIL Code Generation is the first level of .NET compilation in which the high-level compiled in to a language called Intermediate Language (IL). The IL code look more like machine code than high-level language, but the IL does contain some abstract concepts such as base classes and  exception handling, which is why the language is called intermediate.

MSIL includes instructions for loading, storing, initializing, and calling methods on objects, as well as instructions for arithmetic and logical operations, control flow, direct memory access, exception handling, and other operations. When a compiler produces MSIL, it also produces metadata.

Metadata describes the types in your code, including the definition of each type, the signatures of each type’s members, the members that your code references, and other data that the runtime uses at execution time.

1.3.4 Just-In-Time Compiler

CPU-independent MSIL code can be efficiently converted to native code using Just-in-Time (JIT) compiler, only when that portion of IL code is required for execution.

JIT generated machine code is CPU-specific code that runs on the same computer architecture as the JIT compiler and it takes advantage of the added instruction sets offered by each CPU type.

1.3.5 Executing Code

When CLR executes a .NET method for the first time, it generates a processor specific native code from MSIL using the JIT compiler. The next time the method is run, the existing JIT-compiled native code is run.

The process of JIT-compiling and then executing the code is repeated until execution is complete. CLR provides myriad set of services to managed components like garbage collection, versioning, interoperability with unmanaged code, etc.

1.3.6 Assemblies

An assembly is a collection of types and resources that forms a logical unit of functionality. All types in the .NET Framework must exist in assemblies; the common language runtime does not support types outside of assemblies.

Each time you create a Microsoft Windows  Application, Windows Service, Class Library, or other application with Visual Basic .NET, you’re building a single assembly. Each assembly is stored as an .exe or .dll file.

The .NET Framework uses assemblies as the fundamental unit for several purposes:

  • Security
  • Type Identity
  • Reference Scope
  • Versioning
  • Deployment

1.3.7 Assembly Manifest

Every assembly contains an assembly manifest, a set of metadata with information about the assembly. The assembly manifest contains these items:

  • The assembly name and version
  • The culture or language the assembly supports (not required in all assemblies)
  • The public key for any strong name assigned to the assembly (not required in all assemblies)
  • A list of files in the assembly with hash information
  • Information on exported types
  • Information on referenced assemblies

In addition, you can add other information to the manifest by using assembly attributes. Assembly attributes are declared inside of a file in an assembly, and are text strings that describe the assembly. For example, you can set a friendly name for an assembly with the Assembly Title attribute:

<Assembly: AssemblyTitle(“Test Project”)>

assembly-manifest
assembly-manifest

 

1.3.8 An End to DLL Hell

DLL hell is a common term for various problems associated with the use of dynamic link libraries (DLLs) or DLL files. A DLL file is a resource within the Windows operating system that  contains code and data related to the functionality of one or more applications.

These files, which may have the file extension .dll or other file extensions, have been a major building block for the Windows operating system and Windows programs since the early MS-DOS versions of Microsoft’s computer technology. Successive versions of Windows have illustrated certain problems with the use of DLL files for many different programs.

From a customer perspective, the most common versioning problem is what we call DLL Hell. Simply stated, DLL Hell refers to the set of problems caused when multiple applications attempt to share a common component like a Dynamic-Link Library (DLL) or a Component Object Model (COM) class.

In the most typical case, one application will install a new version of the shared component that is not backward compatible with the version already on the machine. Although the application that has just been installed works fine, existing applications that depended on a previous version of the shared component might no longer work.

In some cases, the cause of the problem is even more subtle. For example, consider the scenario where a user downloads a Microsoft ActiveX control as a side effect of visiting some Websites. When the control is downloaded it will replace any existing versions of the control that were present on the machine.

If an application that has been installed on the machine happens to use this control, it too might potentially stop working. In many cases there is a significant delay before a user discovers that an application has stopped working.

As a result, it is often difficult to remember when a change was made to the machine that could have affected the application. A user may remember installing something a week  ago, but there is no obvious correlation between that installation and the behavior they are now seeing.

To make matters worse, there are few diagnostic tools available today to help the user determine what is wrong. The reason for these issues is that version information about the different components of an application aren’t recorded or enforced by the system.

 

Advertisements