Elements of the .NET Framework
Your grasp of the suitability of the .NET Framework and Visual Basic .NET to tackle problems within your business or those of your clients can depend on how well you understand major elements of the .NET Framework. A full discussion of these elements is well beyond the scope of this book. Nevertheless, this section presents selected background on three helpful elements of the .NET Framework: the common language runtime (CLR), preparations to run source code, and assemblies.
For those with a desire to learn more about the .NET Framework architecture, I recommend Introducing Microsoft .NET, Second Edition by David S. Platt (Microsoft Press, 2002). Another resource is available to those with Visual Studio .NET installed on their machine. After you install Visual Studio .NET, you can open the .NET documentation from the Start menu by selecting All Programs, Microsoft Visual Studio .NET, and then choosing Microsoft Visual Studio .NET Documentation. While this documentation includes some material that overlaps with the Help files from within Visual Studio .NET, the documentation also contains background material that enriches your understanding of a topic instead of just explaining how to perform a task.
Common Language Runtime
The common language runtime, or CLR, is a run-time engine for all languages that are compatible with .NET. This runtime interprets code and enables it to run on an operating system, much like the Access run-time engine or VBRUN does. The notion of a runtime engine for compiling or interpreting code is common among current languages. In fact, the Java language gains a substantial degree of its notoriety because of its run-time engine.
The CLR for the .NET Framework is a run-time engine for all languages compatible with .NET. The CLR and its components implement the compiled source code that you write in Visual Basic .NET. Not all languages have to expose the same set of features from the CLR, but any capabilities that languages supported by .NET expose must first be available in the CLR. For this reason, applications created with different languages supported by .NET are fully interoperable.
Because the CLR delivers programming functionality to all languages, it can deliver traditional as well as some nontraditional services. One of the most popular nontraditional services is garbage collection . The CLR automatically disposes of memory references when they are no longer needed. Through its automatic garbage ( unused references ) collection feature, the CLR helps to eliminate memory leaks, which is a particularly common problem with applications that enable the instantiation of the same object by many users or repeated instantiation of the same object by a single user . Garbage collection makes obsolete the practice of removing an object from memory by setting its reference to Nothing . The automatic aspect of garbage collection frees the CLR to pick a time for removing unused references that has minimal impact on your application s performance.
| Note | Garbage collection is all about memory management. While you do not need to set reference variables pointing at objects to Nothing , your code should still release other system resources such as files and database connections when they are no longer needed. |
The programming capabilities available through the CLR derive from its base class library. Earlier in this chapter, I mentioned that Visual Basic .NET developers can program data tasks with ADO.NET and Web tasks with ASP.NET. Both ADO.NET and ASP.NET correspond to components within the base class library that implement specialized functionality. The .NET Framework represents these components in the class library with one or more namespaces. For example, the System.Web namespace supports ASP.NET functionality.
A namespace can contain a set of related types. Types are entities that you can use in your programs, such as classes, delegates, enumerations, interfaces, and structures. Classes are designs for objects that have properties, methods , and events as type members. (Other members of this group include fields and nested types.) Within Visual Basic .NET, delegates facilitate event processing by helping to manage communication between event senders and event receivers. An enumeration is a related set of constant values defined by an Enum statement. Interfaces are a contract. An interface specifies members that are fulfilled by another entity, such as a class instance. A structure is a user-defined value type.
Table 1-1 describes selected data and XML namespaces that you are likely to use as an Access database developer. These namespaces generally expose types that you can use to implement the features of ADO.NET for Access databases. The descriptions for the System.Data and System.Data.OleDb namespaces highlight their applicability to Access database files. However, these namespaces can work with data from data sources other than Access database files. Depending on the data source, you may find other namespaces appropriate for your needs.
| Namespace Name | Description |
|---|---|
| System.Data.OleDb | Namespace for the OLE DB .NET data provider; permits connecting to, reading data from, and executing commands against Access database files |
| System.Data | Enables disconnected data representations (datasets) from multiple database files by representing data types, relations, and constraints; facilitates data manipulation tasks between disconnected datasets and original Access database files |
| System.Xml | Enables persisting , reading, and processing XML documents based on datasets and other data sources |
The three namespaces in Table 1-1 point to different ways in which you are likely to interact with data in the .NET Framework. First, use the System.Data.OleDb namespace to connect to a data source, such as an Access database file. The conceptual pipe connecting your application to a data source can function like a firehose that supports forward-only, read-only data access, or it can enable disconnected data access. The local copy of data from one or more data sources is a dataset.
Second, your application can make changes to a dataset and then subsequently attempt to synchronize local changes with the corresponding data in the original data source. Access developers know this style of data processing as optimistic locking. The System.Data namespace in coordination with the System.Data.OleDb namespace facilitates this second group of activities.
Third, you can process XML documents with the System.Xml namespace. The architecture for datasets permits them to expose their contents as linked tables ”such as you may view in the Access Relationships window ”and as hierarchical XML documents. See Chapter Appendix for an introduction to XML documents and processing issues.
Running Source Code
Now you know that the CLR ultimately runs your source code. However, the CLR does not read source code, such as Visual Basic .NET. The code that you write in Visual Basic .NET goes through two rounds of compilations before the CLR executes it. These compilations are an integral part of how the .NET Framework delivers its cross-language benefits.
The .NET Framework documentation describes the execution of source code in four steps. The first step is to pick a language compatible with .NET. Just because the .NET Framework exists on your computer doesn t mean you are required to program the computer using .NET. You can still use Visual Basic or VBA to code applications. Code developed with a language that is not compatible with .NET is called unmanaged code , and it does not enjoy the benefits of execution by the CLR. If you use Visual Basic .NET or one of the many other languages supported by .NET, you create managed code , and this code does enjoy the benefits delivered by the .NET Framework. One of these benefits is that your Visual Basic .NET classes can interoperate freely with classes created by developers using other languages, such as C#.
The second step explains why classes coded with Visual Basic .NET can interoperate freely with classes coded with other languages supported by .NET. In the second step, a source code compiler translates the source code to Microsoft Intermediate Language (MSIL). All language compilers in the .NET Framework perform this translation from your source code. The format of MSIL is the same for any language supported by .NET. After conversion to MSIL, all these languages represent applications with the same format.
As a source language compiler creates MSIL, it saves the MSIL in a portable executable file (with either an .exe or a .dll extension). While creating the MSIL for an application, the source language compiler also creates metadata describing the application, and the compilation process stores the metadata in the portable executable file. Every type member in an application is described by the metadata. Therefore, the metadata fully describes the structure of an application. It is this self-description that eliminates the need for type library files.
Metadata supports three important benefits for .NET solutions. First, metadata self-describes files. The storing of metadata with MSIL permits the .NET Framework to use a single file for both definition and implementation. If you were creating solutions with COM, metadata would eliminate the need for Interface Description Language (IDL) files. Second, metadata contains the necessary information for the compiled source code in a portable executable file developed initially with one source language to be inherited by a compiled solution developed with a different source language. (A more precise definition for inheritance appears later in this chapter, but the general notion of inheritance is sufficient here.) No custom programming or any other special steps are necessary to facilitate inheritance of compiled classes across languages. Third, the .NET Framework allows you to annotate your source code with attributes that extend the basic description of an application. In fact, the .NET Framework uses this attribute capability as it defines an XML Web service and the individual methods that an XML Web service exposes (as well as in many other contexts).
The third step in preparing to run source code is the compilation of the MSIL and metadata to native code, which is processor-specific machine code. A second compiler performs this task. The .NET Framework will typically perform this second execution with a just-in-time (JIT) compiler. Because the JIT compiler returns native code, it varies by operating system and CPU architecture. For example, it will differ from 64-bit systems to 32-bit systems. During this second compilation, the JIT compiler checks to make sure an invoked element is type safe. This check verifies that code will not override unauthorized memory locations and maintains isolation from other applications at run time. Unless an administrator explicitly overrides the type safety requirement, the .NET Framework will not run code unless it is type safe.
The just-in-time (JIT) name for the second compiler derives from the fact that the .NET Framework does not compile the MSIL code for the whole application at once. Instead, it compiles a type s member only as a user invokes the member s functionality, allowing the .NET Framework to deliver performance to a user as she calls for it. Members that are not invoked by a user do not require compilation by the JIT compiler. After the JIT compiler operates on the code for a type member, the .NET Framework can store the code for the member in a cache for faster reference the next time a user invokes it. Both JIT compilation and caching compiled native code speed performance.
After JIT compilation, the code is ready to be run by the CLR in the fourth and final step for running source code. By this time, the initial source code has undergone two compilations. This managed code receives special benefits, such as memory management, security, interoperability with unmanaged code, and debugging support. All of these benefits and more derive from the capabilities of the CLR and the JIT compilation of the MSIL code, which is, in turn , based on the source code.
Assemblies
Assemblies are the basic deployment unit for applications and custom classes within the .NET Framework. An individual assembly will typically include one or more modules plus an assembly manifest. A module is a portable executable file. The assembly manifest is metadata for an assembly. For example, an assembly manifest enumerates the files in an application, which can include multiple modules, graphic files, XML documents, Access database files, or other kinds of files. Because the assembly manifest knows about the files within an assembly, the assembly manifest maps requests for type members to individual files within the assembly. In addition, the assembly manifest enumerates other assemblies on which its assembly depends.
| Note | Assemblies can be static or dynamic. Static assemblies, which this section explains, refer to saved assembly files. Dynamic assemblies are created on the fly and used from memory. You can save a dynamic assembly after its use. |
When you are working with Visual Studio .NET, it will automatically create a file directory folder for your Windows application projects. This folder is the assembly for the project. If you have a simple Windows application, your file can have one Windows form. A project s folder can also contain an Access database. By copying the folder to another computer in the exact same location, your application can work on the second computer without any adjustment. If you must copy the folder to a new location on the second computer, you may need to respecify the connection string for linking to the Access database on the second computer.
As the preceding description demonstrates , you can deploy a Visual Basic .NET Windows application to another computer as easily as copying a folder (say, with XCOPY). There is no need to set a reference to a type library or make changes to the registry on the computer receiving the deployed application. For this approach to work, you have to be willing to run the application from the .exe file in the project s solution. If you create multiple versions of a project, you can deploy each version to a different folder or copy over existing folders when they become obsolete. This approach to deployment eliminates DLL hell because everything for an application is contained in a single folder from which your clients run the application.
The assembly construct in the .NET Framework is rich enough to support another deployment model. This second approach takes advantage of a global assembly cache (GAC) for storing assemblies that you must share with two or more other assemblies. When you install the .NET Framework on a computer, the installation process automatically creates a GAC in the assembly folder of the Windows directory. On a Windows 2000 computer, the path to the GAC is \Winnt\assembly. While you cannot use XCOPY to move an assembly to the GAC, you can drag and drop the folder for an assembly into the GAC from Windows Explorer. In addition, the global assembly cache tool (gacutil.exe) that ships with the .NET Framework SDK (and installs with Visual Studio .NET) allows you to view and manipulate the contents of the GAC on a computer. Of course, you must have permission to work with the Windows directory.
Shared assemblies require a strong name before you can store them in the GAC. A strong name uniquely identifies an assembly. You can generate a strong name for an assembly with the strong name tool (sn.exe), which ships with the .NET Framework SDK. After developing a strong name, you must sign an assembly with the strong name for the name to uniquely identify the assembly. You can use the Assembly Linker (al.exe), another .NET Framework SDK tool, to sign an assembly with the key pair generated by the strong name tool.
The .NET Framework uses the terms shared assembly and private assembly to refer to the two types of assemblies. An assembly that operates from its own private folder is called a private assembly. An assembly that other assemblies reference from the GAC is called a shared assembly. You can run different versions of an assembly in side-by-side fashion. Build a new assembly that references a version of an assembly in the GAC, and the new assembly will automatically use the correct version for as long as it is available in the GAC. If you build a second new assembly that references a different version of an assembly in the GAC, this second new assembly will automatically use its version of the supporting assembly for as long as its version is in the GAC.
The .NET Framework documentation recommends against using shared assemblies as a general practice because private assemblies are easier to administer. For example, there is no need to make strong names for private assemblies, and it is easier to copy private assemblies. (You can use XCOPY for private but not shared assemblies.) Shared assemblies must reside in the Windows folder on a computer ”for example, the Winnt folder on a Windows 2000 computer. Administrators often restrict access to the files in the Windows folder to protect its contents. However, this practice can restrict the ability to administer shared assemblies in the GAC.
EAN: 2147483647
Pages: 111