.NET Concepts

Borland is the first independent software vendor to license the .NET Framework from Microsoft. The benefit of this is that applications created with C#Builder are fully compatible with any other .NET application or library.

Because C#Builder is about building .NET applications quickly, it helps to understand why .NET is important, what it is, and how it works. The information in this section is not all-inclusive, but still very important. Understanding this basic information about .NET will enable you to answer many questions in the future.

Why .NET?

In the past, languages, operating systems, and platforms were built for a different age, when the primary platform for applications was the desktop computer. When programs moved from the desktop to the Internet, existing tools needed additional APIs and other capabilities. Most often, these new capabilities were bolted onto the side of the language or tool to coerce them into working on the Internet. Although conventional tools have done remarkably well and brought the Internet to where it is today, there are still many challenges to overcome.

.NET was created to support the new age of Internet computing applications. Issues such as deployment, security, and versioning have become significant problems, which .NET addresses. A central part of .NET is the Common Language Runtime (CLR), a virtual code execution engine that supports deployment, security, and versioning of code. With native compiled code, such capabilities are not possible. Because .NET solves these basic problems, it is a more powerful solution for building Internet-based applications.

What Is .NET?

.NET is a platform for building distributed applications. It is composed of tools including a Base Class Library (BCL), the Common Language Runtime (CLR), and programming languages. These tools enable you to build several types of applications, such as Windows Forms, ADO.NET, ASP.NET, and Web Services.

Windows Forms is a set of libraries for building graphical user interfaces for traditional client applications. They encapsulate much of the Win32 API, providing an object-oriented approach to simplify building Windows client applications.

ADO.NET is a set of object-oriented classes for building data components and data access layers in n-tiered applications. It is architected such that manufacturers can create their own high-performance data providers to their individual databases. C#Builder includes the Borland Data Provider, which targets multiple databases. .NET also includes OleDb and ODBC providers for legacy standards based access to data sources that don't have custom data providers.

ASP.NET includes a Web Forms programming model, in which Web-based applications can be built and run over the Internet and accessed with a browser. This is an improved Web programming model in which code is actually compiled on the server but rendered to the client as traditional HTML. It is object-oriented and supports a server-based component model, promoting reusability.

Web Services are a new platform-independent and standards-based approach for enabling interoperability between heterogeneous systems on the Internet. .NET Web Services use the object-oriented infrastructure of the ASP.NET programming model, but still expose an open-standards message-based model. Using open standards, such as XML, SOAP, WSDL, and UDDI, Web services communicate with any other standards-based Web service implementation, regardless of platform and transport.

These are just a few of the more popular application types that can be built with .NET. If you become familiar with the vast .NET Framework BCL, you will discover that it offers more capabilities to meet any need.

Base Class Library

The .NET Base Class Library (BCL) contains thousands of reusable types that increase productivity in building .NET applications. Because of BCL's size, it takes time to learn everything that is available. You can often save time by searching the BCL before duplicating a custom type that already exists.

As you start out, it is good to get a general overview of what is in the BCL and know where to look. Table 1.1 shows the major namespaces and descriptions of BCL types.

Table 1.1. .NET Namespaces

NAMESPACE	DESCRIPTION
System	The most commonly used types.
System.CodeDom	Allows creating types that automate working with source code, that is, compilers and code creation tools.
System.Collections	Collection types such as ArrayList, Hashtable, and Stack.
System.ComponentModel	Supports building reusable components.
System.Configuration	Types for working with various kinds of XML configuration files.
System.Data	Most of the types for ADO.NET database programming. Other types are in namespaces that are specific to a database or data interface.
System.Diagnostics	Process, EventLog, and Performance Counter types.
System.DirectoryServices	Managed interface for accessing Windows Active Directory Services.
System.Drawing	GDI+ types.
System.EnterpriseServices	COM+ types.
System.Globalization	Types for culture-specific support of calendars, formatting, and languages.
System.IO	Directory, File, and Stream types.
System.Management	APIs for performing WMI tasks.
System.Messaging	Types for working with message queues.
System.Net	Access to networking protocol types.
System.Reflection	Reflection APIs for inspecting assembly metadata.
System.Resources	Types for culture-specific resource management.
System.Runtime	COM Interop, Remoting, and Serialization support.
System.Security	Code access security, role-based security, and cryptography types.
System.ServiceProcess	Types for building Windows Services.
System.Text	Text encoding/decoding, byte array from/to string translation, the StringBuilder class, and regular expressions.
System.Timers	Timer types.
System.Threading	Threads and synchronization types.
System.Web	HTTP Communications, ASP.NET, and Web Services types.
System.Windows	Windows Forms types.
System.XML	All XML support types, including XML Schema, XmlTextReaders/XmlTextWriters, XPath, XML Serialization, and XSLT.

Common Language Runtime

The Common Language Runtime (CLR) is an execution engine with the primary purpose of providing managed execution of .NET code. The central point to remember about the CLR is the word "managed." The CLR manages the execution, versioning, and security of all .NET code. This is why you'll often see .NET or C# code referred to as "managed code." All code that targets the .NET CLR is "managed code." Conversely, when speaking in .NET terms, the word "unmanaged" refers to code that is not managed by the CLR, including executables and libraries that are compiled directly to native machine code.

Managed code is not compiled to native machine code. Rather, it is compiled to Microsoft Intermediate Language (MSIL), which I'll refer to as just IL. Much like Java byte code (or just byte code), IL is an assembler-like language. However, one of the primary conceptual differences between byte code and IL is the fact that IL does not have an interpreted specification. IL is loaded and Just-In-Time (JIT) compiled to machine code in memory by the CLR at runtime. Another difference between Java byte code and IL is that IL is designed specifically to support multiple languages. One could split hairs about semantic differences between byte code and IL, and lengthy discussions persist on public forums, but the fact is that a compiled specification and multilanguage support are the intention of the designers of IL and something that a .NET developer, including C# developers, should be aware of.

.NET programs are composed of assemblies, which are the logical atomic unit of deployment, identification, and security. They differ from traditional executables in that an assembly can consist of one or more files. A .NET assembly is commonly packaged as a single executable or library file, but may also contain modules, which are nonexecutable code units that may be reused in other assemblies.

Assemblies are self-describing. Because they contain their own metadata, there is no need for separate repositories, such as the registry or other catalogs. Assemblies can also be signed and secured, making them safe from other malicious code. A "type" is a named abstraction that may be either intrinsic to the language you're using or a custom defined type. The significance of type safety is that it makes code more robust and helps protect against malicious use of your program. Because C# is a type-safe language, it will detect most type mismatches at compile time and render errors. For example, you wouldn't want to accidentally assign a double type in a scientific application to an integer type. By catching type errors at compile time, you are saved the potentially disastrous effects of missing a runtime error. Also, with type safety, it is harder for malicious code to coerce one type into another in order to manipulate your memory improperly. The CLR verifies the type safety of an assembly for extra protection against those runtime situations that can't be identified at compile time.

Another important feature to know about the CLR is how it loads and executes code. Understanding this process brings home the points of security and type safety. It also gives you insight into performance considerations and memory management. Figure 1.1 demonstrates how the CLR manages the lifetime of an application.

Figure 1.1. CLR application management.

As soon as a .NET program begins execution, Windows detects that this is a .NET assembly and starts up the CLR. The CLR then identifies the program entry point and begins the Resolve Types process, in which it finds out where a given type is located. Identified assemblies are loaded by the Loader process.

This process illustrates why the .NET compiler is called a JIT compiler types are loaded on an as-needed basis or just-in-time. The verification process ensures type safety and security. If the JIT compiler encounters a type that it needs, it will consult the Resolve Types process to find and load the necessary assembly, so that it can continue.

The initial JIT compilation represents a noticeable performance hit, occurring when an application first starts. Subsequent performance of loads will vary, depending on the type retrieved. As hinted, these are only initial delays, and performance improves greatly after a type has joined the in-memory working set.

After a type has been compiled to machine code, the memory manager handles it. Value types (structs) are allocated on the stack and reference types (classes) are allocated on the heap. Periodically, the garbage collector kicks in to clean up unused heap objects in a mark-and-sweep fashion. The garbage collector maintains generations, cleaning up newer unused objects before older ones. With additional optimizations, a garbage collection on average is no more intrusive than a typical page fault.

In-memory code is native machine code that has already been JIT compiled and can be fed directly to the CPU. The in-memory working set will remain in place until memory pressure causes a garbage collection. The generational behavior and other optimizations of the memory manager help prevent page faults in active code, resulting in greater performance.

When the CPU needs to execute type members that are not in memory, it will request that type from the JIT compiler. Because of optimizations, execution/JIT-Compilation/Resolution cycles are minimized. The important point to understand is that it is this cycle that causes performance loss. For small programs this is generally not a problem because it will be easier to keep the working set in memory. However, for larger programs you will want to release unused objects as soon as they are no longer needed. This relieves memory pressure and helps keep the primary working set in memory.

The CLR is central to all that happens in .NET. Understanding how it works is the key to writing well-behaved code that performs efficiently.

Programming Languages

Another important part of .NET is the concept of multilanguage support. IL is designed to support many languages. In fact, there are currently dozens of languages that target the CLR by compiling to IL. Besides C#, .NET ships with Visual Basic .NET, JScript .NET, J# .NET, and Managed C++. Other vendors include Borland Delphi .NET, Fujitsu COBOL .NET, Python .NET, Perl .NET, and many others.

The glue that holds all these languages together is referred to as the Common Type System (CTS). Although each language represents types in a unique manner, the underlying behavior and semantics of each type are the same to the CLR. The CTS defines which members a type may have: Field, Methods, Events, Properties, and Indexers. It also specifies their scope and visibility: public, internal, protected, protected internal, and private. Of course, this description is given through the perspective of C# keywords: Other languages may differ in keyword, but the underlying semantics of the CLR remain the same.

Why multiple languages? For a better perspective of the reasoning behind this approach, consider a large business with multiple software projects. It is often the case that the languages in many of these projects are different. Unless the developers are using a component technology such as COM, they are probably not getting much reuse of code between projects. Having multiple languages that target a single platform has more potential for reuse, which is an important business benefit.

The ability to code in multiple languages has benefits in business-to-business commerce also. The third-party component market is huge, with more companies joining the .NET arena every day. These companies can code their components in any .NET language they choose. These components are reusable by any other .NET application, regardless of the language it is being written in. Multiple language support in .NET opens new markets to component vendors that, in the past, might have been difficult to support and reach.

MULTIPLE LANGUAGE SUPPORT BENEFITS

Multiple language support in .NET helps make the most of existing talent with a specific language. If you have a group of developers who have been programming COBOL for years, retraining is minimal to begin receiving the benefits of .NET. Additionally, they can reuse libraries written in other languages, without caring what that other language is. Let me make this clear: I don't support working a single project with multiple languages, as I believe it would create a disruptive environment and make the code difficult to maintain. What I am saying is that if project A developers create reusable components (DLLs) written in C#, project B developers, who program in COBOL, can use those components without caring what language they were written in. Multiple languages provide an easy on-ramp to .NET for developers from diverse development backgrounds.

Of course, compatibility between programming languages is not absolute or automatic. Many languages have unique aspects that other languages will not recognize. For example, a VB .NET application will not work with a C# DLL with a public method that exposes pointer types.

The Common Language Specification (CLS) was created to address these problems. The CLS is essentially a least common denominator specification of what languages are allowed to expose if they want to communicate among themselves. For example, C# is not allowed to publicly expose pointers and unsigned types if it wants to be CLS-compliant. Libraries that want to be CLS-compliant may use their non-CLS-compliant features in private code, but not in their public interface.

C#Builder is an excellent tool for building .NET applications. Familiarity with how the CLR works and the many reusable classes in the BCL will help you build efficient and well-designed applications with C#. The rest of this book will explain in greater detail how to write .NET applications with the C#Builder Integrated Development Environment (IDE).