Sams Teach Yourself .Net in 21 Days

By Jason Beres

• Table of Contents
  • Copyright
  • About the Author
  • About the Technical Editor
  • Acknowledgments
  • We Want to Hear from You
  • Introduction
  • Week 1: At a Glance
  • Day 1. Introduction to the Microsoft .NET Framework
    • What Is .NET?
    • Windows of the Past
    • The Common Language Runtime
    • Understanding the Common Language Specification
    • Understanding the Common Type System
    • Handling Memory and Garbage
    • The .NET Framework Class Library
    • What about C++?
    • .NET Servers and the Future of .NET
    • Summary
    • Q&A
    • Quiz
    • Exercises
  • Day 2. Introduction to Visual Studio .NET
  • Day 3. Writing Windows Forms Applications
  • Day 4. Deploying Windows Forms Applications
  • Day 5. Writing ASP.NET Applications
  • Day 6. Deploying ASP.NET Applications
  • Day 7. Exceptions, Debugging, and Tracing
  • Week 1. In Review
  • Week 2: At a Glance
  • Day 8. Core Language Concepts in Visual Basic .NET and C#
  • Day 9. Using Namespaces in .NET
  • Day 10. Accessing Data with ADO.NET
  • Day 11. Understanding Visual Database Tools
  • Day 12. Accessing XML in .NET
  • Day 13. XML Web Services in .NET
  • Day 14. Components and .NET
  • Week 2. In Review
  • Week 3: At a Glance
  • Day 15. Writing International Applications
  • Day 16. Using Macros in Visual Studio .NET
  • Day 17. Automating Visual Studio .NET
  • Day 18. Using Crystal Reports
  • Day 19. Understanding Microsoft Application Center Test
  • Day 20. Using Visual SourceSafe
  • Day 21. Object Role Modeling with Visio
  • Week 3. In Review

The Common Language Runtime

At the heart of the .NET Framework is the common language runtime. The common language runtime is responsible for providing the execution environment that code written in a .NET language runs under. The common language runtime can be compared to the Visual Basic 6 runtime, except that the common language runtime is designed to handle all .NET languages, not just one, as the Visual Basic 6 runtime did for Visual Basic 6. The following list describes some of the benefits the common language runtime gives you:

• Automatic memory management
• Cross-language debugging
• Cross-language exception handling
• Full support for component versioning
• Access to legacy COM components
• XCOPY deployment
• Robust security model

You might expect all those features, but this has never been possible using Microsoft development tools. Figure 1.3 shows where the common language runtime fits into the .NET Framework.

Figure 1.3 The common language runtime and the .NET Framework.

Inside the Common Language Runtime

The commonlanguage runtime enables code running in its execution environment to have features such as security, versioning, memory management, and exception handling because of the way .NET code actually executes. When you compiled Visual Basic 6 forms applications, you had the ability to compile down to native node or p-code. Figure 1.4 should refresh your memory of what the Visual Basic 6 options dialog looked like.

Figure 1.4 Visual Basic 6 compiler options dialog.

When you compile your applications in .NET, you aren't creating anything in native code. When you compile in .NET, you're converting your code—no matter what .NET language you're using—into an assembly made up of an intermediate language called Microsoft Intermediate Language (MSIL or just IL, for short). The IL contains all the information about your application, including methods, properties, events, types, exceptions, security objects, and so on, and it also includes metadata about what types in your code can or cannot be exposed to other applications. This was called a type library in Visual Basic 6 or an IDL (interface definition language) file in C++. In .NET, it's simply the metadata that the IL contains about your assembly.

When a user or another component executes your code, a process occurs called just-in-time (JIT) compilation, and it's at this point that the IL is converted into the specific machine language of the processor it's executing on. This makes it very easy to port a .NET application to any type of operating system on any type of processor because the IL is simply waiting to be consumed by a JIT compiler.

Understanding the process of compilation in .NET is very important because it makes clear how features such as cross-language debugging and exception handling are possible. You're not actually compiling to any machine-specific code—you're simply compiling down to an intermediate language that's the same for all .NET languages. The IL produced by J# .NET and C# looks just like the IL created by the Visual Basic .NET compiler. These instructions are the same, only how you type them in Visual Studio .NET is different, and the power of the common language runtime is apparent.

When the IL code is JITted into machine-specific language, it does so on an as-needed basis. If your assembly is 10MB and the user is only using a fraction of that 10MB, only the required IL and its dependencies are compiled to machine language. This makes for a very efficient execution process. But during this execution, how does the common language runtime make sure that the IL is correct? Because the compiler for each language creates its own IL, there must be a process that makes sure what's compiling won't corrupt the system. The process that validates the IL is known as verification. Figure 1.5 demonstrates the process the IL goes through before the code actually executes.

Figure 1.5 The JIT process and verification.

When code is JIT compiled, the common language runtime checks to make sure that the IL is correct. The rules that the common language runtime uses for verification are set forth in the Common Language Specification (CLS) and the Common Type System (CTS).

Share This