Nbsp;   Loading the Common Language Runtime

Each assembly you build can be either an executable application or a DLL containing a set of types for use by an executable application. Of course, the CLR is responsible for managing the execution of code contained within these assemblies. This means that the .NET Framework must be installed on the host machine. Microsoft has created a redistribution package that you can freely ship to install the .NET Framework on your customers’ machines. Some versions of Windows ship with the

.NET Framework already installed.

You can tell if the .NET Framework has been installed by looking for the MSCorEE.dll file in the

%SystemRoot%\System32 directory. The existence of this file tells you that the .NET Framework is installed. However, several versions of the .NET Framework can be installed on a single machine simultaneously. If you want to determine exactly which versions of the .NET Framework are installed, examine the subdirectories under the following directories.

%SystemRoot%\Microsoft.NET\Framework

%SystemRoot%\Microsoft.NET\Framework64

The .NET Framework SDK includes a command-line utility called CLRVer.exe that shows all of the CLR versions installed on a machine. This utility can also show which version of the CLR is being used by processes currently running on the machine by using the –all switch or passing the ID of the process you are interested in.

Before we start looking at how the CLR loads, we need to spend a moment discussing 32-bit and 64-bit versions of Windows. If your assembly files contain only type-safe managed code, you are writ- ing code that should work on both 32-bit and 64-bit versions of Windows. No source code changes are required for your code to run on either version of Windows. In fact, the resulting EXE/DLL file produced by the compiler should work correctly when running on x86 and x64 versions of Windows. In addition, Windows Store applications or class libraries will run on Windows RT machines (which use an ARM CPU). In other words, the one file will run on any machine that has the corresponding version of the .NET Framework installed on it.

On extremely rare occasions, developers want to write code that works only on a specific version of Windows. Developers might do this when using unsafe code or when interoperating with unman- aged code that is targeted to a specific CPU architecture. To aid these developers, the C# compiler offers a /platform command-line switch. This switch allows you to specify whether the resulting assembly can run on x86 machines running 32-bit Windows versions only, x64 machines running 64- bit Windows only, or ARM machines running 32-bit Windows RT only. If you don’t specify a platform, the default is anycpu, which indicates that the resulting assembly can run on any version of Windows. Users of Visual Studio can set a project’s target platform by displaying the project’s property pages, clicking the Build tab, and then selecting an option in the Platform Target list (see Figure 1-3).

In Figure 1-3, you’ll notice the Prefer 32-Bit check box. This check box is only enabled when Plat- form Target is set to Any CPU and if the project type produces an executable. If you select the Prefer 32-Bit check box, then Visual Studio spawns the C# compiler specifying the /platform: anycpu­ 32bitpreferred compiler switch. This option indicates that the executable should run as a 32-bit

executable even when running on a 64-bit machine. If your application doesn’t require the additional memory afforded to a 64-bit process, then this is typically a good way to go because Visual Studio does not support edit-and-continue of x64 applications. In addition, 32-bit applications can interop- erate with 32-bit DLLs and COM components should your application require this.

FIGURE 1-3Setting the platform target by using Visual Studio.

Depending on the platform switch, the C# compiler will emit an assembly that contains either a PE32 or PE32+ header, and the compiler will also emit the desired CPU architecture (or agnostic) into the header as well. Microsoft ships two SDK command-line utilities, DumpBin.exe and CorFlags.exe, that you can use to examine the header information emitted in a managed module by the compiler.

When running an executable file, Windows examines this EXE file’s header to determine whether the application requires a 32-bit or 64-bit address space. A file with a PE32 header can run with a 32- bit or 64-bit address space, and a file with a PE32+ header requires a 64-bit address space. Windows also checks the CPU architecture information embedded inside the header to ensure that it matches the CPU type in the computer. Lastly, 64-bit versions of Windows offer a technology that allows 32-bit Windows applications to run. This technology is called WoW64 (for Windows on Windows 64).

Table 1-2 shows two things. First, it shows what kind of managed module you get when you specify various /platform command-line switches to the C# compiler. Second, it shows how that application will run on various versions of Windows.

TABLE 1-2Effects of /platform on Resulting Module and at Run Time

After Windows has examined the EXE file’s header to determine whether to create a 32-bit or 64- bit process, Windows loads the x86, x64, or ARM version of MSCorEE.dll into the process’s address space. On an x86 or ARM version of Windows, the 32-bit version of MSCorEE.dll can be found in the

%SystemRoot%\System32 directory. On an x64 version of Windows, the x86 version of MSCorEE.dll can be found in the %SystemRoot%\SysWow64 directory, whereas the 64-bit version can be found in the %SystemRoot%\System32 directory (for backward compatibility reasons). Then, the process’s primary thread calls a method defined inside MSCorEE.dll. This method initializes the CLR, loads the EXE assembly, and then calls its entry point method (Main). At this point, the managed application is up and running.1

If an unmanaged application calls the Win32 LoadLibrary function to load a managed assembly, Windows knows to load and initialize the CLR (if not already loaded) in order to process the code contained within the assembly. Of course, in this scenario, the process is already up and running,

and this may limit the usability of the assembly. For example, a managed assembly compiled with the /platform:x86 switch will not be able to load into a 64-bit process at all, whereas an execut- able file compiled with this same switch would have loaded in WoW64 on a computer running a 64-bit version of Windows.

1 Your code can query Environment’s Is64BitOperatingSystem property to determine if it is running on a 64-bit version of Windows. Your code can also query Environment’s Is64BitProcess property to determine if it is running in a 64-bit address space.

Date: 2016-03-03; view: 792