What Is .NET?

Since Microsoft first announced and released .NET, people have been trying to figure out what exactly this new 'thing' is. According to the marketing that Microsoft was pushing, it would revolutionize computing as we know it. That's an awfully big promise to keep, and it's still too early to tell if it really will accomplish its goals. However, it is well on its way to doing so.

When people talk about .NET, you can never be sure which "component" of .NET they're talking about. No other "product" or "idea" released by Microsoft has taken on so many different forms. There are products, services, and even concepts that are tagged with the .NET moniker, so it's hard to figure out what exactly .NET is.

When .NET is discussed in this book, it will be in reference to the new development languages and runtime available with the .NET Framework SDK (which is included on the accompanying CD). This SDK includes the .NET Runtime, which contains everything you need to run applications written for the .NET environment. You can think of the .NET Runtime as consisting of several components. The components of the CLR reside in the Global Assembly Cache (GAC). The compilers for the Microsoft .NET languages are also included (C#, VB .NET, VJ#, and so on). You can see the GAC in Figure 1.1.

Figure 1.1. The Global Assembly Cache.

One of the most common misconceptions people have about running .NET code is that the code being executed is "interpreted," much like Java byte code or the old visual basic runtimes are. The truth is that code written for .NET is compiled natively before it is ever executed. When a .NET application is compiled, it is compiled into an intermediary language ( IL ) . This IL is actually what is stored in the executable or library that has been created.

This IL will be compiled into native code at one of two points. At the installation time of the code, a process called ngen (short for native generation ) can be performed. This compiles the IL directly into native code, and stores the compiled native code in a special place in the GACthe native assembly cache. Assuming the code wasn't compiled at installation time, it must be compiled before the first execution. During startup of the application, a special feature of the .NET Runtime called the JIT (Just In Time) compiler performs the compilation in the background.

You can imagine that in the latter case, the startup time of your application could be negatively affected because of this compilation happening behind the scenes. If startup time is important to your application (which it should be if you're writing games ), it would be wise to ensure that your installation includes the ngen step. However, some optimizations can't be made during this step that can be made if the code is compiled via the JIT, so if the startup time isn't important, feel free to let the .NET Runtime do what it was designed to do.

What Is Managed Code?

Managed code will be mentioned quite often during the course of this book. The API that will be used throughout the book is called Managed DirectX, and it's not uncommon at all to hear the .NET languages called the managed languages . The managed term comes from the fact that the .NET Runtime has a built-in memory manager.

In the "old days" (you remember, just a few years ago), developers who were writing code in C and C++ would have to do their own memory management. Allocated memory would have to be freed when it was no longer necessary, unless you wanted that memory to "leak," which could be the cause of horrible performance later on down the line. Even worse , because you were dealing directly with pointers, it's quite easy to corrupt the memory your project is using. In many cases, this leads to long debugging sessions because in the majority of cases where you actually see the error occurring is nowhere near where the memory originally became corrupt.

The C and C++ languages have a reputation of being "hard" mainly because of many of these types of issues. Many developers were reluctant to try out C or C++ because of this reputation, and thus tried out some other high-level languages that could eliminate these headaches , such as Visual Basic. Although these new languages did have the benefits of being easy to use and learn, they also had drawbacks. The performance of these other languages wasn't competitive with C and C++, at most times noticeably slow. Also, because the underlying operating system was developed using C++, not all of the features were available in these other languages. Although you could do quite a bit of good work using them, if you wanted all the power, performance, and features available with the operating system, you were on your own, if it was possible at all.

With the release of the first version of the .NET Runtime, much of this changed. Microsoft went back to the drawing board, designed an entirely new API, and tried to make sure developers' concerns were addressed. This new Runtime had to be easy to use, it had to be fast, and it had to eliminate the headaches of memory management. Throughout this book, you will see how well they actually achieved these goals.

Flylib.com

Category list

Similar pages

What Is .NET?

What Is .NET?

Figure 1.1. The Global Assembly Cache.

What Is Managed Code?

Similar products