Pro Visual C++-CLI And The .NET 2.0 Platform (2006) [eng]-1

xl	■I N T R O D U C T I O N

Chapter 19: “Security”

.NET is touted as being an extremely secure software environment, and this is evident with the plethora of .NET Framework security features. In this chapter, you will see how you can access many of them using C++/CLI.

Chapter 20: “Unsafe C++ .NET Programming”

This chapter takes a look at what is involved in mixing and matching unsafe C++, also known as unmanaged C++ or traditional C++, with Safe/Managed C++/CLI. If you have some legacy C++ code that you want to migrate to .NET, this is the chapter for you.

Chapter 21: “Advanced Unsafe or Unmanaged C++ .NET Programming”

Unlike other books, which cover this topic, this book looks at advanced unsafe C++ from the eyes of someone who is coding in C++/CLI and wants to integrate some unsafe or unmanaged code into his or her existing code. (Usually the approach is the opposite, i.e., a developer is coding unsafe or unmanaged code and trying to force it into the C++/CLI environment.) It will regard the unsafe/unmanaged code as a black box that you will attach to your C++/CLI code in different fashions, depending on the type of unsafe/unmanaged code to which you are connecting.

What You Need to Use This Book

The first thing you should probably do is download the code for this book from the Downloads section of the Apress Web site (http://www.apress.com) or from http://www.ProCppCLI.net. Most of the code in the book is listed in its entirety, but some of the larger programs (in particular, the Windows Forms applications) list only relevant code.

In addition to the source code, you should have a copy of Visual Studio 2005 final beta or later. Note that most, but not all, the features mentioned in the book work with the Visual C++/CLI Express 2005 version.

As long as you have the .NET Framework version 2.0 and its associated C++/CLI compiler, however, you should be able to build nearly everything in the book (though with a lot more effort).

■Caution This book contains material that isn’t supported in Visual Studio .NET 2003 and the .NET Framework 1.1 or earlier.

This Book Is Not the End of the Story

A book is a pretty static thing, and once you finish reading it, you have to go elsewhere for more information. Fortunately, I have built a Web site devoted entirely to Visual C++/CLI and the .NET 2.0 Platform: http://www.ProCppCLI.net.

On this site, you will find not only all the source code for this book, but also further writings on C++/CLI by me and other authors. The Web site’s goal is to promote further exploration of C++/CLI and thus it will also contain news, a discussion area, an area to upload your code, and an area to download third-party code.

■I N T R O D U C T I O N

xli

How to Reach Me

I would like to hear from you. Feel free to e-mail me at [e-mail] or [e-mail]. If you have a question and you think others would benefit from the answer, ask it on the http://www.ProCppCLI.net discussion board. I will respond to every e-mail and discussion entry that I can. Questions, comments, and suggestions are all welcome.

Oh, by the way, thank you for buying my book. Now, let’s get started!

P A R T 1

■ ■ ■

The C++/CLI Language

C H A P T E R 1

■ ■ ■

Overview of the .NET Framework

First off, let’s get one thing straight. This book is about developing code within the confines of the Microsoft .NET Framework 2.0. Therefore, it only makes sense that you start by getting acquainted with the underlying architecture with which you will be developing your code: the .NET Framework.

I cover a lot of material in this chapter, mostly at the 30,000-foot level. The main goal here isn’t to make you a .NET Framework expert. This chapter is designed to provide you with a level playing field from which to start your C++/CLI code development while exploring this book.

I start with a brief description of what the .NET Framework is and why we programmers need it. Then, I briefly examine the assembly, which is the central building block for all .NET Framework application distribution and execution. Next, I move on to the core of .NET Framework: the common language runtime (CLR), the common type system (CTS), and the common language specification (CLS). Finally, I discuss, at a very high level, the software components available to .NET Framework developers.

What Is .NET?

To put it in the simplest of terms, .NET is Microsoft’s strategy to move from a client-centric model to a network-centric model. Another way of looking at it is that the impact of .NET will be the following:

•For programmers: A paradigm shift in the approach to software development and deployment.

•For architectures: Internet processing power to be distributed more on the Web clients and less on the Web servers via Web deployment, enabling much better use of the Internet.

•For the future of the Internet: Ultimately, the Internet will become more an operating system and less a means of simply connecting computers together.

These things are mostly about the future. What does .NET mean to programmers here and now? The first major change that you will see with .NET is that the medium for software deployment will change from full-functionality CD-ROM installations to much smaller, as-needed-functionality Internet downloads. Microsoft calls this “Click-once” deployment or smart clients.

.NET provides the functionality to place small elements of your application programs on a Web server. These elements can then be downloaded on an as-needed basis, when that application is executing. Basically, applications run as described in these steps:

3

4C H A P T E R 1 ■ O V E R V I E W O F T H E . N E T F R A M E W O R K

1.A user attempts to start an application using the .NET runtime.

2.The runtime checks to see if an up-to-date version of the application is in the system’s global assembly cache. If it is, the runtime executes it from the cache; otherwise, the runtime downloads the updated version and then executes it.

3.While the application is running, it may require other elements. When one such element is required, the runtime checks the cache to see if it exists. Then, the runtime makes one further check to ensure the element is up to date. If there is no version in the cache, or it is not up to date, then the element is downloaded.

As you can see, this is considerably different from how it is done now, whereby everything is placed on a CD-ROM and installed at one time. I’m sure you can see that the .NET method ensures that the “latest and greatest” are always being executed.

Does this mean that the only way of distributing software is via the Internet? No, there is nothing stopping you from distributing the old way or even combining the two methods, in which you install everything up front and then use the Internet to keep everything up to date.

As you can imagine, developers now have to start designing their software in a much more modular fashion. Developers also have to be conscious of what modules will likely go together so that those modules can be downloaded concurrently to mitigate the amount of time a user has to wait between running different functionalities of the application. This will also allow for more efficient usage of the Internet.

Another major aspect of .NET that developers will become quickly aware of is that applications are no longer restricted only to the computer on which they are running. It is now possible to execute code from Web services on computers anywhere around the world. True, with some complex coding such as DCOM, COM+, and CORBA, you could, before the advent of .NET, escape the sandbox of the application host computer. But now with .NET, the code to access the resources of the Internet is nearly effortless. Equally as easy, it is possible to make your resources available to the Internet. With

.NET, IIS, and a domain or IP, a computer does not have to be an island.

■Note Wherever you read the word “Internet,” you can assume “intranet” and “extranet” apply as well.

What Is the .NET Framework?

The .NET Framework comprises all the pieces needed to develop, deploy, and execute Web services, Web applications, Windows services, Windows applications, and console applications. (Well, almost all the pieces. IIS is needed for Web services and Web applications.) I discuss each of these in more detail later in the chapter. You can think of the .NET Framework as a three-level hierarchy consisting of the following:

•Application development technologies like Web services, Web Forms, and Windows Forms

•.NET Framework base classes

•CLR

This hierarchy is illustrated in Figure 1-1.

C H A P T E R 1 ■ O V E R V I E W O F T H E . N E T F R A M E W O R K

5

Figure 1-1. The .NET Framework hierarchy

Each of the layers in Figure 1-1 is dependent on the layer beneath it. The CLR lies just above the operating system and insulates the programmer from its intricacies. The CLR is what actually loads, verifies, and executes Web services, Web Form applications, Windows services, Windows applications, and console applications.

The .NET Framework base classes are a large number of classes broken up by namespaces containing all the predeveloped functionality of .NET. They contain classes to handle things such as file I/O, database access, security, threading, graphical user interfaces, and so on. As a C++/CLI developer, you will spend many hours perusing and using these classes.

The application development technologies provide a higher layer of abstraction than the base classes. C++/CLI developers will use these technologies to build their Web applications, Web services, and Windows applications. Most of the functionality a developer needs can be found at this level of abstraction, but in those cases where more control is needed, the developer can dive down into the base classes level.

.NET Programming Advantages

The .NET Framework was designed and developed from day one to be Internet aware and Internet enabled. It uses technologies such as SOAP and XML as its underlying methods of communication. As a developer, you have the option of probing as deeply as you wish into each of these technologies, but with the .NET Framework, you have the luxury, if you want, of staying completely ignorant of them.

You have probably heard that .NET is language neutral. This key feature of .NET is handled by

.NET compilers. It is currently possible to develop code using the languages provided by Microsoft, (C++/CLI, C#, J#, JScript .NET, and Visual Basic .NET) or in one of the many other languages provided by third parties (such as COBOL, Delphi, and Perl). All .NET-compatible languages have full access to the .NET Framework class library. I cover .NET multilanguage support briefly in this chapter.

6 C H A P T E R 1 ■ O V E R V I E W O F T H E . N E T F R A M E W O R K

Another thing you have probably heard whispers about is that .NET can be platform independent. This means that it is possible to port the .NET Framework to non-Windows platforms and then run it without recompiling .NET applications and services. The reason for this is that .NET-compatible code is compiled into something called assemblies, which contain code, along with several other things, in an intermediate language. I cover assemblies briefly in this chapter and then delve into the art of working with them in Chapter 18.

■Note It is true that the .NET Framework can be ported. Two such ports, Mono and DOTGNU, for the Linux platform are probably the best-known ports of the .NET Framework. Microsoft has also provided Rotor for multiple platforms such as MAC and BSD Unix.

If you’ve been coding and deploying Windows code in C++ for any length of time, I’m sure you’ve become painfully aware that it’s anything but simple. Now, if you’ve gone beyond this to build distributed applications, the complexity has multiplied many times over. A key design goal of the

.NET Framework is to dramatically simplify software development and deployment. Some of the most obvious ways that the .NET Framework does this are as follows:

•It usually shelters you from the complexities of the raw Windows Application Programming Interface (API). However, there are several APIs in the Win32 that don’t exist in .NET and still require the use of P/Invoke to gain access. I cover P/Invoke in Chapter 21.

•It provides a consistent, well-documented object model, and with it, users can create their own consistent self-documented object models.

•Managed code is used to create objects that can be garbage collection. You no longer have to worry about memory loss because you forgot to delete allocated pointers. In fact, if you use managed code, you don’t even have to deallocate pointers because the .NET Framework does not use pointers; instead it uses handles, and the .NET Framework does the deleting of allocated memory for you.

•The intricacies of COM and COM+ have been removed. To be more accurate, COM and COM+ are not part of the .NET Framework. You can continue to use these technologies, but

.NET supports them by placing COM and COM+ components in a class-library-derived wrapper. You no longer have to worry about things such as the VARIANT, IUnknown, IDL, and so on.

•Deployment components no longer use the registry or special directories.

•Deployment is frequently as simple as an xcopy.

A Closer Look at the .NET Framework

Okay, you have looked at .NET and the .NET Framework in general terms. Now, let’s break it into the elements that are relevant to a C++/CLI programmer and then look at each element in some detail. There are five major elements that a C++/CLI developer should have at least a basic knowledge of before attempting to code:

•Assemblies

•CLR

•CTS

•CLS

•.NET Framework class library

C H A P T E R 1 ■ O V E R V I E W O F T H E . N E T F R A M E W O R K

7

Each element impacts the C++/CLI programmer differently. Assemblies are a new form of binary distribution. The CLR is a new way of executing. The CTS is a new way of defining datastorage types. CLS is a specification of language-neutral support. The .NET Framework class library is a whole new set of development objects to learn. I discuss each of these elements in more detail in the following sections.

Assemblies

You need a basic understanding of assemblies before you can learn about any other element of the

.NET Framework. I cover some basic information about assemblies in this chapter and then discuss working with them in detail in Chapter 18.

Figure 1-2. The basic assembly structure

Assemblies are the core building blocks for all .NET Framework application distribution and execution. They are generated after compiling C++/CLI code. Like pre-.NET application deliverables, they end with either .exe or .dll, but that is pretty well as far as the similarities go.

Basic Structure

Assemblies are a self-describing collection of functionalities stored in an intermediate language and/or resources needed to execute some portion of an application. Assemblies are made up of four sections: the assembly metadata, type metadata, Microsoft intermediate language (MSIL) code, and resources (Figure 1-2). All sections except the assembly metadata are optional, though an assembly made up of just assembly metadata sections won’t do anything.

Assemblies can be either private or shared. Private assemblies reside in the same directory as the application itself or in one of its child directories. Shared assemblies, on the other hand, are stored in the global assembly cache (GAC). The GAC is really nothing more than a directory structure that stores all the assemblies that are globally available to the computer (Figure 1-3). A neat feature of the GAC is that more than one version of the same assembly can reside in it.