Introducing .NET
(Page 1 of 2 )
If you're looking for a basic introduction to the .NET framework, this article is a great place to start. It is excerpted from chapter one of the book
Start-to-Finish Visual Basic 2005: Learn Visual Basic 2005 as You Design and Develop a Complete Application, written by Tim Patrick (Addison-Wesley; ISBN: 0321398009).
Welcome to .NET! I might as well have said, “Welcome to the Solar System,” because like the solar system, .NET is huge. And it’s complex. And it’s filled with black holes and other things that don’t always make sense. Yet it (.NET, not the universe) turns out to be a fantastic system in which to develop software applications.
The .NET Framework was not developed in a vacuum (unlike the universe); Microsoft designed it and its related development languages—especially C# and Visual Basic—to address various issues that plagued Windows software developers and users. To fully understand why .NET was necessary, we need to take a short trip down computer memory lane.
Before .NET Practical general-purpose computers have been around since the mid-twentieth century. However, they were inaccessible to most people because (a) they cost millions of dollars, (b) they consumed gobs of electricity, (c) maintenance and programming could only be done by highly-trained specialists, and (d) they tended to clash with the living room furniture.
Fast forward about 30 years. IBM comes out with the “personal” computer. These “desktop” computers represented a great advance in technology, but only a minority of people ever used them. They continued to be expensive (thousands of dollars), and maintenance and programming still required significant investments in training. IBM PCs also looked hideous around the living room furniture.
Then came the Apple Macintosh. With its sleek design and its user-friendly functionality, it introduced the joy of computing to the masses. And while programming it was not always straightforward, it did give nice results. It’s no wonder that Bill Gates decided to copy—oops, I mean improve upon—its functionality.
Microsoft Windows 1.0 brought a greater level of usability to the IBM/Intel computing platform. But it wasn’t a free ride for programmers. MS-DOS development was hard enough without the addition of the “message pumps” and the hundreds of Application Programming Interface (API) calls needed by Windows programs. Visual Basic 1.0, introduced in 1991, greatly simplified the development process, but with the advent of 32-bit systems, ActiveX and COM components, and the Web, even VB programmers soon felt overwhelmed.
Throughout the 1990s, the situation only seemed to worsen. Microsoft saw increased competition in the form of the Java language and the Linux operating system. Hackers were exploiting buffer overruns and other security issues present in the Windows platform. Users experienced myriad computer problems stemming from conflicting standards, competing data integration technologies, registry bloat, and “DLL hell.” In frustration, an Excel user’s group set fire to the entire Microsoft campus in Redmond.
Well, it didn’t get that bad. But Microsoft did see that it needed to address the overall software development and usability issues on its beloved Windows platform. Its solution came in the form of the .NET Framework.
Back to Introducing .NET
When Microsoft announced its plans for .NET, it surprised many developers, especially Visual Basic developers, who saw it as a giant step backward for “Rapid Application Development.” But the release of the .NET Framework version 1.0 in 2002 did bring many needed benefits.
- .NET introduced a unified programming environment. All .NET-enabled languages compile to “Microsoft Intermediate Language” before being assembled into platform-specific machine code. Visual Basic and C# are language wrappers around this common .NET “language.” Because all .NET-enabled compilers speak the same underlying language, they no longer suffer from the many data and language conflicts inherent in other component-based systems such as COM. The .NET version of Visual Studio also unified the standard user interface that lets programmers craft source code.
- .NET committed developers to object-oriented technologies. Not only does .NET fully embrace the object-oriented programming paradigm, everything in .NET is contained in an object: all data values, all source code blocks, and the plumbing for all user-initiated events. Everything appears in the context of an object.
- .NET simplified Windows programming. Programming in Visual Basic before .NET was easy enough, until it came time to interact with one of the API libraries, something that happened a lot in professional programming. With .NET, most of these APIs are replaced with a hierarchy of objects providing access to many commonly needed Windows features. Because the hierarchy is extensible, other vendors can add new functionality without disrupting the existing framework.
- .NET enhanced security. Users and administrators can now establish security rules for different .NET features to limit malicious programs from doing their damage. .NET’s “managed” environment also resolved buffer overrun issues and memory leaks through features such as strong data typing and garbage collection.
- .NET enhanced developer productivity through standards. The .NET Framework is built upon and uses many new and existing standards, such as XML and SOAP. This enhances data interchange not only on the Windows platform, but also in interactions with other platforms and systems.
- .NET enhanced Web-based development. Until .NET, a lot of Web-based development was done using scripting languages. .NET brings the power of compiled, desktop development to the Internet.
- .NET simplified the deployment of applications. If .NET is installed on a system, releasing a program is as simple as copying its EXE file to the target system (although an install program is much more user-friendly). Features such as side-by-side deployment, ClickOnce deployment (new in 2005), and an end to file version conflicts and “DLL hell” (the presence of multiple versions of the same DLL on a system, or the inability to remove a version of a DLL) make desktop and Web-based deployments a snap.
If you didn’t understand some of the terms used in this section, that’s all right. You will encounter them again, with explanations, in later chapters.
The .NET Object To fully understand software development in .NET, you must understand what an object is. (If you are familiar with object-oriented programming—OOP—then you can probably skip down to the next section, although you will miss some really great content.) Although some of this section’s information will also appear in Chapter 8, “Classes and Inheritance,” it is so important to the discussion of .NET that a portion appears here as well.
Objects and Data
From a programming standpoint, a computer performs four basic tasks:
- It stores data in the computer’s memory area.
- It supports processing of this data through basic operations, including addition and subtraction, Boolean algebra, and text string manipulation.
- It allows the user to interact with the data stored in memory.
- It provides a way to bring the data in and out of memory, through input and output devices such as keyboards and printers, and through long-term storage media, such as hard drives.
The core of these four activities is data. Computers exist to manipulate data. Operating systems provide the basic foundation for these activities, but it is software applications that make these features—the ability to manipulate data—real and meaningful to the user. High-level programming languages are the primary tools used to develop these applications, each of which uses some general methods to make data manipulation features available to the programmer. Back in the good old days of assembly language development, if you knew the memory address of a piece of data, you could access and manipulate it directly. In early flavors of BASIC and in most other “procedural” languages, data was accessed through variables.
As languages grew in complexity and purpose, so did their view of data. In the LISP (short for “List Processing” or “Lots of Irritating Silly Parentheses”) language, any data value exists within a larger list or set of data. But in .NET languages, data is viewed through the object.
Objects are collections of data values and associated source code. Whereas in older BASIC dialects, each data element was more or less independent through its named variable, related data values in OOP languages can be grouped into objects. Objects often include source code designed to manipulate the data values of that object.
Objects generally represent some thing, often a thing that has a real-world counterpart, whether physical or conceptual. For instance, your code may include a House object that has data fields or properties for the address, the exterior paint color, and the number of people living in the house. Associated source code could manage that data; a Paint method could alter the color value used for the exterior paint.
The data and code elements within an object are called members. Some members are hidden inside the object and can be accessed only by the object’s source code. Other members are more public; any code in your application can use them, not just that subset of application code found inside the object. Consider a television as an object (see Figure 1-1).
Figure 1-1. A TV: It’s an object, not just objectionable.
The public members of a TV are generally easy to use: the power button, channel selector, volume control, and so on. They are the conduits through which the user controls the data values of the TV (its video and audio output). There are also hidden members inside of the TV; you could use these members to impact the picture and sound quality, although this would be a bad idea for most users. You don’t want me messing with the internal members of your TV set, trust me. In the same way, an object doesn’t want code outside of the object to mess with its internal members except through the public members. I don’t care how a TV works internally, as long as I can get pictures and sound out of it by using the controls that are exposed (power, channel, volume).
Objects and Interfaces
The public members of an object represent its interface. If code outside of the object wants to manipulate the data belonging to that object, it uses the members of the interface. It doesn’t have to figure out the hidden members or how they work, and that’s good. It’s especially good if those internal members ever change for any reason, which happens more often then you think. Consider how the internals of TVs have changed just in the last 30 years. Here’s a drawing of the TV my family had when I was a kid. Compare it with modern flat-screen TVs available today (see Figure 1-2).
Figure 1-2. Are those really TVs?
My family’s TV was cool. It had an AM/FM stereophonic hi-fi radio, a turntable that could play 33-1/3, 45, and 78 RPM records, and a large 19inch display with vivid black-and-white crystal-clear display. You could hide two kids behind it when playing hide and seek. And my friend who had the same model said that you could draw these really cool permanent lines on the screen with a magnet. Who cares that the speaker panels looked like vertical shag carpet? Who cares that the unit took up 30 percent of the floor space in the room? Who cares that you could cook sausages on top of it from the heat generated by the vacuum tubes? It was more than a TV; it was an entertainment center.
Now compare it to the wimpy little flat screen job on its right. If you look closely, you find that the interface to the TV hasn’t really changed much in three decades. There are still controls for power, volume, and channel selection (although Horizontal Hold and Vertical Hold are gone, sniff). What has changed is the internal configuration. Gone are the humming vacuum tubes, all replaced with efficient transistors and solid-state components. But it doesn’t really make much difference to the TV viewer, because the public interface remains the same.
Objects in OOP development work in the same way. As long as the public interface remains the same, the object’s actual code and internal data storage system—also known as the object’s implementation—can change with no impact to the overall application.
Objects and Instances The interface and implementation of an object really only represent its design; these are the parts created through the source code. They exist even before the program is compiled and installed on the user’s computer. In fact, at this level, objects really aren’t even known as objects. In most languages (including Visual Basic), the word class indicates the implementation of an object’s interface.
Once your application is installed on a computer and starts up, the code creates instances of the class to store actual data in memory. These instances are the true objects of OOP development. Depending on how your code is written, a single class implementation might create just one or hundreds of objects in memory at the same time.
In .NET, all of your code and data values appear inside of objects. Pretty much everything you see in a running program is an object: Windows forms are objects; a list box control on that form is an object; and a single item in that list box is an object.
THE PARTS OF THE .NET FRAMEWORK
So now you know all about objects, and you are probably thinking it’s time to toss this book into the pile and start programming. But there are a few more parts of the .NET Framework still to discuss. These parts show up ad nauseum in the .NET documentation, and they each have a three-letter acronym (TLA), or thereabouts.
The Common Language Runtime At the center of the .NET Framework is the Common Language Runtime (CLR), so named not because it is common or ordinary, but because all .NET-enabled languages share it in common. Everything you do in a .NET program is managed by the CLR. When you create a variable, thank the CLR and its data management system. When you say goodbye to a piece of data, thank the CLR and how it manages the release of data through its garbage collection system. Did you notice how the word “manage” keeps showing up in those sentences? My editor sure did. But “manage” is the mot juste, because that is what the CLR does. In fact, software written for the .NET Framework is called managed code. Any code that falls outside of the CLR’s control, including COM (ActiveX) components used by your .NET application, is known as unmanaged code.
The CLR is a lot like Los Angeles International Airport. If you have ever been to LAX, you know that there is a whole lot of activity going on. Airplanes arrive and depart each minute. Cars by the thousands enter and leave the two-level roadway and the central parking structures. People and pickpockets move constantly between the eight main terminals and the massive international terminal. There’s a lot happening, but so much of it is managed. Planes cannot take off or land without approval from the control tower. Access points and gates manage the roadways and parking garages. Friendly, courteous security personnel manage the flow of passengers and pickpockets into and out of the secure areas of the terminals.
The control and management structures in place at LAX ensure an orderly and secure flow of people between its planes and the city of Los Angeles. The control and management structures of the CLR ensure an orderly and secure flow of data between .NET code and the rest of the computer or connected network.
You’d probably like to know the secret of how the CLR is able to process programs written in any .NET language, including Visual Basic, C#, and Fortran. So would Microsoft’s competitors. Actually, they do know, because there is no secret. All .NET-enabled languages convert (that is, “compile”) your source code into Microsoft Intermediate Language (or MSIL, pronounced “missile,” and more commonly abbreviated as just IL).
For those of you familiar with assembly language, it looks a lot like that. For those of you not familiar with assembly language, it looks a lot like gibberish. For example, here is some Visual Basic source code for a console application (a non-Windows text-based program, like the old MS-DOS programs) that simply outputs “Hello, World!” from a code procedure called “Main.”
Module Module1
Sub Main()
Console.WriteLine("Hello, World!")
End Sub
End Module
That’s the whole .NET program. When the Visual Basic compiler converts it to IL, the “Main” procedure looks like this (slightly modified to fit on this page).
.method public static void Main() cil managed
{
.entrypoint
.custom instance void [mscorlib]System.
STAThreadAttribute::.ctor() = ( 01 00 00 00 )
// Code size 11 (0xb)
.maxstack 8
IL_0000: ldstr "Hello, World!"
IL_0005: call
void [mscorlib]System.Console::WriteLine(string)
IL_000a: ret
} // end of method Module1::Main
Yes, it is gibberish. But that’s okay, because it fulfills the International Computer Book Association’s requirement that every Chapter 1 include a “Hello, World” code sample. Also, the CLR understands it, and that’s what really counts in .NET. As long as you can get your code into IL, .NET will process it. The Visual Basic compiler just happens to generate IL for you. Other .NET language compilers, including C#, target IL as well. You can even write your own IL code, but you’re probably reading the wrong book for that. Just to put your mind at ease, this will be the last bit of IL you will see in this book.
The Common Language Specification
Languages that claim to support .NET cannot just say so for any old reason. They truly have to be compatible with .NET and its workings. This is done through the Common Language Specification (CLS). The CLS defines a minimum set of features that a language must implement before it is considered to be .NET-compliant, or more accurately, CLS-compliant.
A language can go way beyond that minimum if it wants, and .NET includes many additional features upon which language-specific features may be built. A language that only implements the minimum CLS-specified features may not be able to fully interact with components from languages that exceed the minimum specification. Visual Basic is, of course, CLS-compliant, and in fact goes way beyond that minimum.
The Common Type System Because the CLR is controlling your source code anyway, Microsoft thought it would be good to have it control the source code’s data as well. The .NET Framework does this through its Common Type System (CTS), which defines all of the core data types and data mechanisms used in .NET programs. This includes all numeric, string, and Boolean value types. It also defines the object, the core data storage unit in .NET.
The CTS divides all data objects into two buckets. The first bucket, called values types, stores actual data right in the bucket. If you have a 32-bit integer value, it gets put right in the value type bucket, ready for your immediate use. The other bucket contains reference types. When you look in this bucket, you see a map that tells you where to find the actual data somewhere else in the computer’s memory. It seems like value types are easier to use, and they are, but they come with a few restrictions not imposed on reference types.
Programs and components written using the CTS standard can exchange data with each other without any hindrances or limitations. (There are a few .NET data types that fall outside of the “core” CTS types, but you only need to avoid them when you want to specifically interact with components that can only use the core CTS types.)
When you write your applications in Visual Basic, most of your code will appear in classes. Classes are reference types that include both data values and associated code. The data values included in a class are most often the core CTS data types, but they can also contain objects that you design elsewhere in your application. Visual Basic also includes structures, the weaker yet quicker younger brother of classes. Structures implement value types, and also include both data and code.
Classes and structures are just two of the data/code types available in Visual Basic. Interfaces are class and structure skeletons; they include design details of what should appear in a related class or structure, but don’t include any actual implementation or working code. Delegates define a single procedure (but not its implementation), and are used to support events, those actions (initiated by the user, by the operating system, or by your code) that tell your code, “Get to work now!” Sea otters are aquatic mammals that are curiously related to the weasel, and like to eat sea urchins. Modules are blocks of code and data, but unlike classes and structures, you can’t create independent objects from them. Enumerations group a set of related integer values, generally for use as a list of choices.
In .NET parlance, all of these terms (class, structure, interface, delegate, module, and enumeration, but not sea otter) are known collectively as types. You probably already knew that .NET had some confusing elements in it; you wouldn’t have bought a book about it if it was easy. But despite all of the complex technology, it is this simple word “type” that causes the most confusion. You will likely experience some angst throughout this book each time you read it. The problem: It’s too general. Not only does it refer to these core elements of the Common Type System, but it is also used when talking about just the Visual Basic-specific value types (more often called the Visual Basic “data types”). The nickname for structures is “user-defined types,” yet another confusing use of “type.” Programmers who used Visual Basic before its .NET incarnation also remember “Type” as the language statement used to create user-defined types. Arrrgh! Microsoft should have used some word other than “types” for the world of classes, interfaces, enumerations, and so on. “Bananas” would have been a better choice because it is only sometimes used to discuss software. But “type” is the word, so you better get used to seeing it. I will try to include as much context as possible when using the word throughout this volume.
The members of a type usually consist of simple data fields and code procedures, but you can also include other types as members. That is, a class can include a nested class if it needs to. Only certain types support nesting (see Chapter 8 for details). I also talk about access levels in that chapter. Each member has an access level that says what code can use that member. There are five access levels, ranging from Public (anybody and their brother can use the member) to Private (you have to be inside the type to even know it’s there).
Chapter 6, “Data and Data Types,” discusses the .NET type system in greater detail, including the information you crave on classes, structures, and other bananas.
.NET Class Libraries
Computers are actually quite stupid. While I can count all the way to 17, a computer tops out at 1; it only knows the digits 0 and 1. The CPU includes a set of simple operators used to manipulate the digits 0 and 1, and a few more operators that compare 1s and 0s in complex ways. The computer’s last great trick is its ability to move 0s and 1s into and out of memory, but whoop-dee-doo. Sure it does these things at nearly the speed of light, but can it calculate π to three million decimal places?
Well, actually it can. Computers don’t know anything about the letters of the alphabet, and they really only can handle the digits 0 and 1, yet here I am using a computer to write an award-winning book. It is the ability to combine the simple one-bit data values and operators into increasingly complex libraries of functionality that make useful computers possible.1
The .NET Framework is built upon decades of increasingly complex functionality. When you install the .NET Framework, the CLR and its associated type system represent the core of the framework. By itself, the framework includes all of the basic functionality needed to let you add 2 and 2 together and correctly get 4. And as a business application developer, you spend a lot of time doing just that. But what if you want to do something more complex, something that you know some other programmer has already done, like sorting a list of names or drawing a colored circle on a form? To get that answer, go to the class libraries, the .NET Class Libraries. These libraries, installed with the Framework, include a lot of pre-written (increasingly complex) functionality that you don’t have to write from scratch.
There are two class libraries in .NET: the Base Class Library (BCL) and the Framework Class Library (FCL). The BCL is smaller, and contains the most essential features that a program just couldn’t do without. It includes only those classes that are an absolute must for supporting applications on the framework if Microsoft were, say, to port the framework to Linux.
The FCL is larger, and includes everything else Microsoft thought you would want to have in your programs, but was not absolutely essential to have in the BCL. Don’t even ask how many classes there are in the FCL; you don’t want to know. I bet that Microsoft doesn’t even really know the full number. I am convinced that those wacky pranksters at Microsoft have included “gag” classes in the FCL, but they are so deeply buried that few programmers ever encounter them.
With thousands (yes, thousands!) of classes, enumerations, interfaces, and other types included in the BCL and FCL, you would think that it would be hard to find just the class you need. But it’s not that difficult, at least not overwhelmingly difficult. The .NET Framework includes a feature called namespaces. All types in .NET appear in a hierarchy—a treelike structure—with just a few minimal entries at the root. Each node in the hierarchy is a namespace. You uniquely identify any class or other type in the libraries by naming all of the namespaces, from the root down to the local namespace that contains the class, separating each node with a period (.).
Unlike most hierarchies that have all branches starting from a single root node, the .NET namespace hierarchy has multiple root nodes. The largest root namespace is named System. It includes many classes, but it also includes several next-tier hierarchy nodes (namespaces). Because the framework includes features for both Windows-based and Web-based application development, there are namespaces that contain the Windows-specific and Web-specific development features. These namespaces appear just within the System namespace, and are called Windows and Web. All code related to on-screen Forms in the Windows namespaces appears in the Forms namespace, and within this namespace is the actual class that implements a form, named Form. Figure 1-3 presents an image of this namespace subset.
Figure 1-3. A hierarchy of namespaces and classes
In Visual Basic, you identify a class by qualifying it with all of its namespaces, starting from its root namespace. The Form class has the following fully qualified name:
System.Windows.Forms.Form
All classes and types exist somewhere in the hierarchy, although not every class descends from System. Many of the supporting features specific to Visual Basic appear in the Microsoft.VisualBasic namespace, which has “Microsoft” as its root node instead of “System.” When you create new projects in Visual Basic, the name of the project is, by default, a new top-level node in the hierarchy. If you create a new Windows application, the default “Form1” form has the following fully qualified name:
WindowsApplication1.Form1
This new application’s namespace is not just a second-class appendage hanging off of the System namespace. It is fully integrated into the full .NET namespace hierarchy; the WindowsApplication1 namespace is a root node, just like the System and Microsoft root nodes. Visual Basic includes features that let you alter the default namespace for your application, or place one of the application’s classes in a specific namespace. You can even place your application’s classes in the System namespace branch. Changing WindowsApplication1 to System.MySuperApp moves Form1 to:
System.MySuperApp.Form1
If your application is actually a component or library destined for use in programs, your app’s classes will appear in the namespace you specify when the other program loads your component into its application area. Your code will look like it is part of the Microsoft-supplied namespaces. Is that cool or what?
Although you can add your classes to the System namespace, you will incur the wrath of other .NET programmers. The System namespace is supposed to be for “system” (read: Microsoft-supplied) features, and that’s it. Also, there’s a chance that two vendors might use the same namespace path. So, to avoid potential namespace conflicts and dirty looks from other programmers, you should name your application’s classes as:
CompanyName.ApplicationName.ClassName
A single class or other type cannot be split across multiple namespaces, even within the same hierarchy branch. However, two classes or types may share a common name in different namespaces, even within the same branch.
All classes of the BCL and FCL appear intermingled throughout the entire namespace hierarchy. This means that you cannot necessarily tell whether a particular class is from the BCL or the FCL. Frankly, it doesn’t really matter; your code won’t care which library a class comes from, as long as it is available for use on the user’s workstation.
Assemblies and Manifests An assembly is a “unit of deployment” for the parts of a .NET application or library. In 99.9% of cases, an assembly is simply a .NET executable file (an “exe” file) or a .NET library of classes and other types (a “dll” file). It is possible to split an assembly between multiple files, but usually it is one file for one assembly.
What makes an ordinary exe or dll file an assembly is the presence of a manifest. For single-file assemblies, the manifest appears right in the file; it can also appear in a file of its own. The manifest is a chunk of data that lists important details about the assembly, including its name, version information, default culture, information on referencing external assemblies and types, and a list of all the files contained in the assembly. The CLR will not recognize an assembly without its manifest, so don’t lose it.
Assemblies can include an optional strong name. This helps to ensure the integrity and authenticity of an assembly through a digital signature attached to the manifest. The strong name uses public key cryptography to guarantee that the assembly is unique and has not been tampered with. Visual Studio and the .NET Framework include tools that let you add a strong name to an assembly.
When you deploy your application, you will normally place all assembly files, configuration files, and any related files specific to your application in the application’s install directory, just like in the old Jurassic days before .NET. Shared assemblies designed to be used by more than one application on a single machine can be stored in the global assembly cache (GAC). All assemblies placed in the GAC must have strong names. Some systems may only allow the system administrator to add assemblies to the GAC.
Metadata and Attributes
Assemblies are brought to you by the letter “m.” In addition to manifests and type members, assemblies also contain metadata. The application code and data elements stored in an assembly parallel the code and data items found in the related Visual Basic source code; for each type and member in your source code, there is associated executable code in the deployed assembly. This makes sense, and is not much of a change from pre-.NET deployments. What is different is that the Visual Basic compiler now attaches additional information—metadata—to each type and member in the assembly. This metadata documents the name of the associated content, information about required data types, information on class inheritance for the element, and security permissions required before the element can be used by the user or other software.
Your Visual Basic source code can enhance the metadata for any element of your assembly through attributes. The metadata generated by an attribute is more than just some ID number. Attributes implement full .NET classes, with their own data values and associated logic. Any .NET code that knows how to process attributes can examine the attributes for a type or member and take action as needed. This includes Visual Studio, the Visual Basic compiler, and your own custom applications.
How’s this for a mundane example: The .NET Framework includes an attribute named ObsoleteAttribute. This attribute lets you mark types or members of your assembly as obsolete or no longer supported. (Visual Studio uses this attribute to display a warning whenever you attempt to use an out-of-date BCL or FCL feature.) To use the attribute, add it to a member of your application using angle brackets.
Class MyClassWithOldMembers
<ObsoleteAttribute> Sub DoSomeWork()
End Sub
End Class
Next: The Parts of the .NET Framework continued >>
More .NET Articles
More By Addison-Wesley/Prentice Hall PTR
