Tag Archives: .VB

Chapter 1(Part 4)Introduction to Visual Basic


Also, changes made to the system on behalf of one application will typically affect all applications on the machine–building an application today that is completely isolated from changes is not easy.

One reason why it’s hard to build an isolated application is that the current run-time environment typically allows the installation of only a single version of a component or an application. This restriction means that component authors must write their code in a way that remains backward compatible, otherwise they risk breaking existing applications when they install a new component. In practice, writing code that is forever backward compatible is extremely difficult, if not impossible.

In .NET, the notion of side-by-side is core to the versioning story. Side-by-side is the ability to install and run multiple versions of the same component on the machine at the same time. With components that support side-by-side, authors aren’t necessarily tied to maintaining strict backward compatibility because different applications are free to use different versions of a shared component.

1.3.9 Global Assembly Cache (GAC)

Each computer where the common language runtime is installed has a machine-wide code cache called the global assembly cache. The global assembly cache stores assemblies specifically designated to be shared by several applications on the computer.

You should share assemblies by installing the in to the global assembly cache only when you need to. As a general guideline, keep assembly dependencies private, and locate assemblies in the application directory unless sharing an assembly is explicitly required. In addition, it is not necessary to install assemblies into the global assembly cache to make them accessible to COM interop or unmanaged code.

There are several ways to deploy an assembly into the global assembly cache:

  • Use an installer designed to work with the global assembly cache. This is the preferred option for installing assemblies into the global assembly cache.
  • Use a developer tool called the Global Assembly Cache tool (Gacutil.exe), provided by the .NET Framework SDK.
  • Use Windows Explorer to drag assemblies into the cache.

Administrators often protect the WINNT directory using an Access Control List (ACL) to control write and execute access. Because the global assembly cache is installed in the WINNT directory, it inherits that directory’s ACL. It is recommended that only users with Administrator privileges be allowed to delete files from the global assembly cache. Assemblies deployed in the global assembly cache must have a strong name.

When an assembly is added to the global assembly cache, integrity checks are performed on all files that make up the assembly. The cache performs these integrity checks to ensure that an assembly has not been tampered with, for example, when a file has changed but the manifest does not reflect the change.

  • The Common Type System

The Common Type System defines how data types are declared, used, and managed in the runtime, and is also an important part of the runtime’s support for the Cross Language Integration. The common type system performs the following functions:

  • Establishes a framework that enables cross-language integration, type safety, and high performance code execution.
  • Provides an object-oriented model that supports the complete implementation of many programming languages.
  • Defines rules that languages must follow, which helps ensure that objects written in different languages can interact with each other.

The Common Type System can be divided into two general categories of types–Reference type and Value type each of which is further divided into subcategories.

  • Classes Notes

Class defines the operations an object can perform (methods, events, or properties) and defines a value that holds the state of the object (fields). Although a class generally includes both definition and implementation, it can have one or more members that have no implementation. An instance of a class is an object. You access an object’s functionality by calling its methods and accessing its properties, events, and fields.

Nested classes also have member characteristics. Class members that have no implementation are abstract members. A class that has one or more abstract members is itself abstract; new instances of it cannot be created.

Some languages that target the runtime allow you to mark a class as abstract even if none of its members are abstract. You can use an abstract class when you need to encapsulate a basic set of functionality that derived classes can inherit or override when appropriate. Classes that are not abstract are referred to as concrete classes.

A class can implement any number of interfaces, but it can inherit from only one base class. All classes must have at least one constructor, which initializes new instances of the class. Each language that supports the runtime provides a way to indicate that a class or class member has specific characteristics. When you use the syntax required by your language, the language ensures that the characteristics of the class and its members are stored (as metadata) along with the implementation of the class.

  • Interfaces

An interface is basically a class definition. It itself cannot be instantiated, rather it is implemented by other classes. Interfaces can be defined and implemented in VB6 albeit with some workarounds and limitations.

For example, in VB6 you cannot use one variable alone to access the methods of the interface and of the implementing class–you have to declare two variables, one as the interface and the other as the implementing class and point both of them to the same instance. VB.NET has a different and more straightforward implementation of interfaces.

Introduction to Visual Basic(Part3)


Because Visual Basic was not tied to the operating systems low-level operations, its programmers had to use library calls to access functions of the Win32 Application Programming Interface (API), the library that “defines” Microsoft Windows.

This also accentuated the difference with other programming environments like Microsoft Visual C++ or other libraries like Microsoft Foundation Class (MFC). In fact, although Microsoft shipped Visual Studio 6 that combined various programming environments with different languages (Visual Basic, C++, ASP, Win32, etc), the only real thing they had in common was that they shipped in the same box (and the same DVD).

To unify the various languages or programming environments that Microsoft had developed for many years, the company created a new library aside from Win32. This was the birth of the .NET Framework. This library is used by, or shared among, different programming languages or environments so that programmers can benefit from a better collaboration.

Now it is possible for people who “speak”, that is, people who program in, different languages to work on the same project with less regard for compatibility issues. This is because (most of) the functions, classes, and resources, are used in conceptually the same way in the different languages.

Microsoft Visual Basic .NET is Microsoft’s implementation of the .NET Framework for Visual Basic programmers. Although Visual Basic .NET is a “child” of Visual Basic 6.0, there are many differences that can be interpreted as a complete shift, with a lot of improvements.

Because of these differences, many already Visual Basic 6.0 programmers resisted the move to this new environment (there were also many other considerations) but those programmers are catching up.

  • Common Language Runtime

The CLR is the execution engine for the .NET Framework. This runtime manages all code compiled with VB.NET. In fact, code compiled to run under .NET is called managed code to distinguish it from code running outside of the framework. Besides being responsible for application loading and execution, the CLR provides services that will benefit component  developers:

  • Invocation and termination of threads and processes
  • Object lifetime and memory management
  • Cross-language integration
  • Code access and role-based security
  • Exception handling (even across languages)
  • Deployment and versioning
  • Interoperation between managed and unmanaged code
  • Debugging and profiling support (even across languages)

Runtimes are nothing new. Visual Basic has always had some form of a runtime. Visual C++ has a runtime called MSVCRT.DLL. Perl, Python, and SmallTalk also use runtimes. The difference between these runtimes and the CLR is that the CLR is designed to work with multiple programming languages.

Every language whose compiler targets the .NET Framework benefits from the services of the CLR as much as any other language..NET is also similar to Java. Java uses a runtime called the Java Virtual Machine.

It can run only with Java code, so it has the same limitations as the other languages. Another distinction is that the JVM is an interpreter. Although all languages in the .NET environment are initially compiled to a CPU independent language called Intermediate Language (which is analogous to Java byte code), IL is not interpreted at runtime like Java.

When code is initially executed, one of several just-in-time (JIT) compilers translate the IL to native code on a method-by-method basis. Cross-language integration is one of the major benefits provided by the CLR. If a colleague has written a base class in C#, you can define a class in VB.NET that derives from it. This is known as cross-language inheritance.

Also, objects written in different languages can easily interoperate. The two parts of the CLR that make this interoperation possible are the Common Type System and the Common Language Specification. The Common Language Runtime (CLR) is the virtual machine component of Microsoft’s .NET framework and is responsible for managing the execution of .NET programs.

In a process known as Just-in-time compilation, the compiled code is converted into machine instructions that, in turn, are executed by the computer’s CPU.

The CLR provides additional services including memory management, type safety and exception handling. All programs written for the .NET framework, regardless of programming language, are executed by the CLR.

It provides exception handling, garbage collection and thread management. CLR is common to all versions of the .NET framework. The CLR is Microsoft’s implementation of the Common Language Infrastructure (CLI) standard. The Common Type System (CTS) defines rules that a language must adhere to in order to participate in the .NET Framework.

It also defines a set of common types and operations that exist across most programming languages and specifies how these types are used and managed within the CLR, how objects expose their functionality and how they interoperate.

The CTS forms the foundation that enables cross-language integration within .NET. The Common Language Specification (CLS) is a subset of the CTS that describes the basic qualities used by a wide variety of languages.

Components that use only the features of the CLS are said to be CLS-compliant. As a result, these components are guaranteed to be accessible from any other programming language that targets .NET. Because VB.NET is a CLS-compliant language, any class, object, or component that you build will be available from any other CLS-compliant programming language in .NET.

Introduction to Visual Basic

Introduction to Visual Basic

  • Managed Execution

The .NET CLR provides a common context within which all .NET applications execute, regardless of the language in which they are written. CLR is responsible for handling every aspects of the managed code such as memory and resource management, secure environment to run in, garbage collection , access to the operating systems services etc. Code that targets the CLR is commonly known as managed code. The managed execution process includes the following steps:

  1. Choosing a proper compiler
  2. Generating MSIL code
  3. Compiling MSIL to CPU specific native code using JIT
  4. Executing the processor specific code.

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.