Basics of the .NET Framework
Using the .NET Framework, Microsoft Visual Basic developers can build robust applications that were very difficult to write in previous versions of Visual Basic. The .NET Framework is Microsoft's latest offering in the world of cross-platform development. In doing so, there have been many changes to the VB language and even the philosophy of developing applications in VB .NET has been forever altered. Although the changes are very positive for VB programmers, they can be a little difficult to become accustomed to.
The .NET Framework is essentially a combination of the common language runtime (CLR) and the standard classes that are available to .NET programmers. The CLR is the execution environment for all programs in the .NET Framework. It is similar in nature to the Java™ virtual machine (VM). The Runtime classes provide hundreds of prewritten services that clients can use as the basic building blocks for an application. We look at these key concepts in a little more detail in the following sections.
Common Language Runtime
The CLR is the new runtime environment shared by every .NET application. Its purpose is to manage code execution along with all of the services that .NET provides.
The CLR is very similar to the concepts used in other languages, such as the VB6 runtime library, a Java virtual machine, or even the Microsoft Foundation Class (MFC) library for C++.
One of the nice features of .NET is that there are many languages that can take advantage of this same runtime (currently C# ['C-Sharp'], VB, and C++). It is the purpose of this runtime to execute the code for any language that was developed for it. Code that was developed for this is called managed code, which can be simply thought of as a relationship between the language and the runtime itself. Because all .NET languages use this same runtime, there is no longer a need for language-specific runtimes. Further enhancing this is the ability of C# programmers and VB programmers to share their code with no extra work.
With the shared runtime, there is a common file format for .NET executable code, which is called the Microsoft intermediate language (MSIL, or just IL). IL is a semicompiled language that is compiled into native code by .NET when the program is executed. This is similar to what all versions of Visual Basic did prior to version 5. This previous method for compiling was known as pseudocode or p-code. With the CLR, the best features of pseudocode and compiled languages are available.
The following list details some of the benefits of using the CLR:
Consistent programming model: All application services are offered via a common object-oriented programming model. This differs from past programming models in which some functions are accessed via DLLs, whereas others are accessed via the COM object.
Simplified programming model: By removing archaic requirements of the Win32 API, .NET seeks to greatly simplify the development process. More specifically, a developer is no longer required to delve into GUIDs, HRESULTS, and so on.
DLL problems: When programmers are using DLLs, they are always concerned with installing components for a new application that can overwrite components of an old application. The old application often exhibits strange behavior or stops functioning altogether because the DLL has changed the way it works. The .NET architecture removes this common problem, and if the application runs after its installation, then the application should always run without the headaches caused by DLL versions.
Platforms: Today, there are many different flavors of Windows, including the three Windows XX variations (Windows® 95, Windows® 98, and Windows® Me), Windows NT® 4.0, Windows® 2000, Windows XP, and Windows® CE. Most of these systems run on x86 CPUs, with the exception of Windows CE devices, which work with Million Instructions Per Second (MIPS) and StrongARM processors. A .NET application that consists of managed code can execute on any platform that supports the .NET common language runtime. This opens some interesting possibilities for the Windows platform and could further be enhanced if the .NET platform is ever ported to platforms such as Linux or the Mac OS.
Reuse of code/language integration: .NET allows languages to be integrated with one another. For example, it is now entirely possible to create a class in C++ that derives from a class first implemented in Visual Basic. The Microsoft Common Language Specification ensures that all .NET languages are implemented in a manner that allows this. Although there are currently the three .NET languages (C#, VB, and C++), there are sure to be many more available in the near future with companies other than Microsoft producing compilers that also target the .NET common language runtime.
Resource management: A common error among applications occurs when a developer forgets to free up resources once they are no longer needed. This can cause a great deal of inconsistency in an application and is sometimes one of the most difficult bugs to track down. Again, the .NET CLR comes to our rescue by automatically tracking resource usage.
Types: The .NET common language runtime can verify that all your code is type safe, which simply means that allocated objects are always accessed in compatible ways. This actually helps in eliminating many common programming errors, but is also advantageous because of the protection of exploitation of buffer overruns used by many hackers.
Error handling: One of the most difficult aspects of programming in Windows is the various ways in which error messages can be reported. For example, some return an HRESULT, whereas others may return a Win32 error code. In .NET, all errors are reported via exceptions, which greatly simplifies maintaining code.
Deployment: This could go side by side with the DLL problems mentioned previously. Past Windows-based applications were incredibly difficult to install and deploy. There can be many files, including data, several DLL files, and Registry settings to deal with-to name a few of the more common examples. .NET components are no longer referenced in the Registry and installing most .NET components can be as simple as copying the files to a directory. Uninstalling can sometimes be an even more difficult task in past Windows-based applications, but with .NET, you can simply delete those same files you installed.
Common type system: The CLR greatly simplifies cross-language communication through the introduction of the common type system (CTS). The CTS defines all of the basic types that can be used in the .NET Framework and the operations that can be performed on those types. Although an application can create a more complex type, it must be built from one of the CTS defined types, which are classes that derive from a base class called System.Object. We look at the CTS in more detail in Chapter 5, Introduction to the VB .NET Language.
The Foundation for NET Development
As was previously mentioned, you can think of the .NET Framework as a foundation on which you build and run applications. Having such a foundation makes it easier to build applications while using a consistent, simplified programming model. In earlier versions of VB, we spent a great deal of time using the Win32 API to do things that we could not natively access in the standard VB functions-things such as accessing Registry keys or creating irregularly shaped forms. Another option was third-party ActiveX controls that are actually very easy to use, but are often expensive for a single project.
This flexibility offered in the Win32 API was a blessing for VB programmers, allowing access to a variety of functions that were otherwise unavailable. Unfortunately, with this power also came a great deal of problems and confusion. Learning the API can be difficult because the calls are complex and, many times, the available examples were written for C++. This made calling the API very error-prone, often resulting in crashed computers and lost hours of coding.
Another problem was the deployment of these applications. After you finally managed to get the API calls working, you then had to deploy the appropriate DLL files with the correct version numbers. You can quickly see why this common framework makes sense from a development standpoint. You still have access to most of the powerful features of the API, without actually knowing how to implement them. In addition, deployment is now very simple because you don't need to concern yourself with how to handle the various DLL files.
API to VB NET
Although the API has not become obsolete, you need to have a quick way to access the various classes that implement the functions you have used in the past. The following BitBlt API call details a portion of a common .NET equivalent:
BitBlt performs a bit-block transfer of the color data corresponding to a rectangle of pixels from the specified source device context into a destination device context. Here is a sample API call and a .NET equivalent:
Listing 4.1 WinAPI.
Declare Function BitBlt Lib "gdi32" Alias "BitBlt" ( _ ByVal hDestDC As Long, _ ByVal x As Long, _ ByVal y As Long, _ ByVal nWidth As Long, _ ByVal nHeight As Long, _ ByVal hSrcDC As Long, _ ByVal xSrc As Long, _ ByVal ySrc As Long, _ ByVal dwRop As Long _ ) As Long
Listing 4.2 .NET.
System.Drawing.Graphics.DrawImage
Summary
In this chapter, we looked at some of the basics of the CLR, CST, and the overall .NET Framework, a topic that encompasses so much information that we could devote an entire volume to its study. In Chapter 5, Introduction to the VB .NET Language, we look at some of the syntax of the VB .NET programming language and take an even greater look at the differences between VB6 and .NET.