Table of Contents

Read a Sample Chapter

MCAD/MCSD: Visual Basic .NET Windows and Web Applications Study Guide

John Wiley & Sons

Chapter One

.NET represents Microsoft's vision and technologies that connect information, people, devices, and systems to form applications. This is a type of distributed computing where software applications will provide services to one another. Microsoft has attached the .NET term to various products that fulfill certain roles in accomplishing Microsoft's vision of distributed computing.

There are the .NET Servers, the server products that provide the necessary infrastructure to support applications that will be delivered over the Internet or over company intranets. These products include Windows .NET Server, SQL Server 2000, Biztalk Server 2002, Exchange Server 2000, Host Integration Server, Application Center Server 2000, SharePoint Portal Server 2002, and Content Management Server. These products provide stand-alone services such as e-mail or connectivity to legacy systems, and you can use them in the applications that you write using the .NET Framework to provide services for data or hosting Web applications.

There is the .NET Framework SDK, which comprises development tools, infrastructure, and libraries that make it easy to build independent software applications, which can communicate with each other and link the computing devices of the world together.

The .NET Framework also provides the Common Language Runtime, which is the successor to COM and overcomes the weaknesses of the COM architecture by providing mechanisms for increased portability, better versioning (through components called assemblies), enhanced security, and ease of programming. It manages your code to make it easier to provide long-running, fault-tolerant, and scalable services. For example, it uses a garbage collection mechanism to prevent memory leaks and can isolate code into application domains, which act as lightweight processes, to provide better performance and increased stability. Microsoft goes one step further and provides the Base Class libraries. These are code libraries, organized into logical groupings called namespaces, that provide the foundations to work with the standards on the Internet, such as XML and HTTP, to build scalable Web or Windows applications. It makes it easy to provide software as a service over the Internet or inside a corporation through the use of Web services. Microsoft is vying to have the best tools and technologies to implement their vision of how the Internet and computers will evolve in the coming years.

This chapter provides an overview of .NET, but it is by no means a comprehensive discussion of .NET. The chapter is designed to help you grasp how .NET works, understand the information presented in this book, and pass the exams for the MCAD and MCSD certifications (which is most likely your primary goal).

NOTE

By the time you sit for exams 70-305 and 70-306, you should have a solid understanding of the .NET Framework. Such coverage is outside the scope of this book. If you are unfamiliar with the .NET Framework, there are a number of books out on the subject, including Visual Basic (r) .NET Programming by Harold Davis, ISBN: 0-7821-4038-6 and Mastering[TM] Visual Basic (r) .NET by Evangelos Petroutsos, ISBN: 0-7821-2877-7, both by Sybex, Inc.

Common Language Runtime

The Common Language Runtime or CLR is the mechanism by which all the code you will write or learn about in this book is executed. The CLR is implemented in a COM in-process server called mscoree.dll. It provides the necessary services to load, execute, and clean up code that is written to the .NET platform. The role of the CLR is similar to that of the Visual Basic runtime or the Java Virtual Machine in that it is responsible for executing the code you develop using the .NET Framework. However, the CLR is radically different in that it does not interpret p-code or byte code, but has been built from the beginning to run native (processor-specific) code. This performs much better than interpreted languages. When you compile your application, you compile to Microsoft Intermediate Language (MSIL) rather than to machine code initially. MSIL acts as a common language for all programming languages, hence the term Common Language Runtime. This is the case regardless of whether you use Visual Basic .NET, C#, C++ with the managed extensions, or any other language with a compiler for .NET. The MSIL is then just-in-time compiled to native code on a method-by-method basis when it is needed. The native code is then cached to avoid having to compile it again if the method is called again. This enables applications to perform well, even though they are using a runtime.

The CLR provides services that manage the code that it executes, which is referred to as managed code (unmanaged code is any code run outside of the services of the CLR). These are core to maintaining various aspects of your code during its lifetime. Table 1.1 describes each of the services provided by the Common Language Runtime.

NOTE

For more information on the CLR, check out VS .NET help at ms-help://MS.VSCC/MS.MSDNVS/cpguide/html/cpconcommonlanguageruntimeoverview.htm.

A .NET language compiler emits more than just MSIL. It also writes out metadata that describes the types and versions of library and executable files (DLLs and EXEs) used by your code. The metadata is stored in a part of the library or executable file and is called the manifest. The manifest replaces the necessity of the system registry, type libraries, COM+ catalog, or other mechanism used by COM to store metadata. This is an improvement over COM, because these external locations are prone to corruption or deletion. This also solves one of the biggest problems with COM's external metadata versioning: side-by-side execution and "DLL Hell".

Side-by-side execution means that you can have multiple versions of the same shared COM library or executable installed on one computer. In COM you had problems with side-by-side execution of two versions of the same application, either on the same machine or even in the same process. (Microsoft allows for side-by-side execution of COM components in Windows 2000 and XP, though it is cumbersome.) .NET allows multiple versions of the same library or executable to exist, so you don't have to upgrade your old application and all of the components and custom or third-party add-ons all at once. You can install the newer version of the application and later upgrade pieces of the old application to take advantage of the new application's features. For example, say you are using the libraries in the .NET Framework to access data and do web programming for your application and a newer version of the .NET Framework is released by Microsoft. You can install it on your machine and your application will continue to use the old version of the .NET Framework it was compiled against until you decide to upgrade it to the new version by recompiling your DLLs to the new version.

Metadata also solves a very familiar problem to those who have installed a lot of software on Windows: "DLL Hell." There is a big problem with versioning in COM applications. This problem tends to arise when components need to be created dynamically through late-binding. The versions of COM libraries your application uses are not stored anywhere with the application and need to be resolved dynamically through the registry when the application is run. This is generally done by passing a ProgID (program identifier), which must be unique to the CreateObject function in VB. If the ProgID is overwritten to point to the newest version of a COM library (DLL) when it is installed on the machine, it could break applications that rely on the older version of the library if the newer version is not 100% compatible with the old program. If the correct version of a DLL is not available when the application runs, the application will not function correctly or may not even run at all. This means that simply installing another application on the system can break the first application. You may have experienced a situation where you installed an application and it updated some DLLs to the newer version-and broke an application you already had installed. After much effort, you probably found that they could not be installed on the same computer, at least not very easily.

.NET solves this problem by allowing developers to control the versions and dependencies between the different software components. These dependencies are then stored in the manifest associated with a .NET assembly. (We will discuss assemblies in greater detail later in this chapter, but for now it is enough to know that an assembly is usually one DLL or EXE file much like COM components.) .NET uses the information in the manifest to maintain application integrity by verifying dependencies and making sure that code has not been changed, and by raising an exception if a change has occurred. Because each assembly carries its own version information, multiple versions of assemblies can be loaded into a process at once and multiple versions of a shared assembly can be tracked, so you don't have to make the choice between applications. Since the manifest is stored in the assembly and not in the system registry, this means that there is no need to register your components when you install them or worry about the registry becoming corrupted. This also reduces the chance of applications interfering with each other's registry settings, and makes deploying applications easier because in most cases all you need to do is copy the DLL to the computer.

The Common Type System

A type is the generic way to refer to any object created in .NET. A type can be a class, structure, enumeration, interface, or array. Types can be used from any of the .NET languages directly. In fact, there is something called the Common Type System (CTS) that permits interoperability between all the .NET languages. This makes using multiple languages for a development project easier, because you don't need to convert data from the format of one language to the other, which was a problem with COM. Each language may have its own specific keyword for creating various primitive types, but they are always compatible because they actually create the same type when compiled to MSIL. If the language you are using does not have a certain type, you can just specify the .NET type directly, as opposed to using a keyword in the language. For example, Visual Basic .NET supports only signed integer types (around -2 billion to 2 billion). Maybe you would like to use an unsigned version because you need a number up to about 4 billion but don't want to use a long because it takes twice as much memory. You could declare a variable as a System. UInt32 even though Visual Basic .NET has no keyword to support this type. Information about types needed at runtime is stored in the assembly's manifest.

Table 1.2 lists the types found in the Common Language Specification, which is a design document that states what you must do and avoid to guarantee that the code written in the different .NET languages are interoperable.

All types in the .NET Framework derive from System.Object . This means that any type, whether it is an Integer or a Customer class, is an object. .NET only differentiates between two types of objects when they are a value type or a reference type.

Value types are allocated on the stack just like primitive types in Visual Basic 6 or C++ and will go out of scope when the block they were declared in exits. All value types derive from System.ValueType; you do not use the new keyword to create a value type because it is not allocated on the managed heap.

NOTE

Actually, you can use the new keyword to declare a value type if you have a parameterized constructor on the value type. This is usually only the case when you work with custom value types.

Reference types are allocated on the managed heap and will therefore be garbage-collected sometime after they go out of scope. They inherit from System. Reference Type, and you use the new keyword to create an instance of a reference type on the managed heap. Here is an example:

'Value types declared and initialized Dim i As Integer = 8 Dim s As MyStruct 'Structure called MyStruct 'Reference types declared Dim obj As New String("Here is a string!) 'String Dim arr() As Integer = new Integer(9) {} 'Array

You can convert from a value type to a reference type by casting the value type to an Object. This is referred to as boxing the type. You can later unbox the object to the original value type by casting it back to the value type. Boxing and unboxing is useful but incurs some overhead. For example, there is a class called ArrayList in the .NET Framework that acts as a dynamic array of any type that you want to give it. Instead of having the Add method take every type, Microsoft had it take an Object. This means that value types would need to be converted or boxed to the reference type Object before being passed to the method. This is an implicit conversion, so you might not even realize it is happening.

There are specialized versions of the data structure classes (such as ArrayList) to support String reference types instead of just generic objects. Since strings are a common item stored in data structures, this helps speed things up by not performing conversions from object to string. Whenever boxing or unboxing occurs, memory is copied from the stack to the managed heap or vice versa, respectively. This takes extra instructions, which translates to extra CPU cycles doing these conversions. If you were doing this in a long loop, you might have a problem with performance in your application. By converting it before going into the loop, you can save instructions and thus improve the performance of your application.

Boxing a value type occurs in the following code:

Dim i As Integer = 14 Dim obj As Object = i

You would unbox the type by using the following code:

Dim j As Integer = CType(obj, Integer)

NOTE

CType is a useful Visual Basic function to convert from one type to another. You pass it the Object reference you want to convert and the type you want to convert it to for the second parameter, and it will return that type or throw an exception if the conversion is not possible.

For more information on the Common Type System in .NET, see the following in Visual Studio .NET help: ms-help://MS.VSCC/MS.MSDNVS/cpguide/html/cpconthecommontypesystem.htm.

Namespaces

The .NET Framework logically (not physically) organizes the types that you create into a namespace. A namespace is a logical organization of your classes, interfaces, and other types that make up your code. Namespaces also help prevent naming conflicts for the types you use. For example, if you are creating an application that integrates customer information from an accounting application and a sales incentive application, both applications might contain a class named Customer. Creating an instance of this class would be difficult because the Namespaces 11 compiler would not know which customer you meant when you typed new Customer(). A namespace would solve this problem by tacking on a unique name in front of the Customer object so you could say new Accounting.Customer() versus new ABC.Customer(). Namespaces are analogous to the COM use of GUIDs to uniquely identify code for ease of use and readability.

When you compile your code, the .NET Framework packages the manifest and MSIL into a DLL or EXE. Namespaces can be nested inside each other to create hierarchies of organization, and can also cross the physical boundaries of the library or executable files.

You create a namespace by using the namespace keyword as follows:

Namespace ABCCompany 'Classes in the ABCCompany namespace can go here

Namespace WebStuff 'Class in the ABCCompany.WebStuff namespace Class Customer 'Customer implementation End Class End Namespace

End Namespace

You must use the namespace to refer to a class you might want to use. For example, if you created a class called Customer in the ABCCompany.WebStuff , you would have to type the following code to create a new instance of the class: Dim c As new ABCCompany.WebStuff.Customer()

If you don't like to type this much, you can shorten it by importing the namespaces you will frequently use and, if there are no name conflicts, avoid typing the whole namespace: Imports ABCCompany.WebStuff

(Continues...)