4.1. The New CLR

The last two releases of.NET (3.0 and 3.5) have been additive releases that build on top of the functionality available in CLR version 2.0 (see Figure 4-1).

Figure 4.1. CLR releases

.NET 4.0 however has a new version of the CLR! So you can happily install .NET 4.0 without fear that it will affect your existing .NET applications running on previous versions of the framework.

4.1.1. ASP.NET

When using IIS7, the CLR version is determined by the application pool settings. Thus, you should be able to run .NET 4.0 ASP.NET applications side by side without fear of affecting existing ASP.NET sites.

4.1.2. What Version of the CLR Does My Application Use?

It depends; applications compiled for earlier versions of the framework will as before use the same version they were built on if it's installed. If, however, the previous framework version is not available, the user will now be offered a choice about whether to download the version of the framework the application was built with or whether to run using the latest version. Prior to .NET 4.0, the user wouldn't be given this choice with the application using the latest version available.

4.1.3. Specifying the Framework to Use

Since almost the beginning of .NET (well, .NET Framework 1.1), you can specify the version your application needs to use in the App.config file (previously as requiredRuntime):

<configuration>
<startup>
  <supportedRuntime version="v1.0.3705"  />
</startup>
</configuration>

The version property supports the following settings:

• v4.0 (framework version 4.0)

• v2.0.50727 (framework version 3.5)

• v2.0.50727 (framework version 2.0)

• v1.1.4322 (framework version 1.1)

• v1.0.3705 (framework version 1.0)

If this setting is left out, the version of the framework used to build the application is used (if available).

When the supportedRuntime property is set, if you try to run the application on a machine that doesn't have the CLR version specified, users will see a dialog similar to Figure 4-2.

Figure 4.2. Dialog showing application targeted for version 1 of the framework

4.1.4. VB.NET Command-Line Compiler

The compiler has a new /langversion switch option that allows you to tell the compiler to use a particular framework version. It currently accepts parameters 9, 9.0, 10, and 10.0.

vbc /langversion:9.0 skynet.vb

4.1.5. Improved Client Profile

Client profile is a lean, reduced-functionality version of the full .NET Framework that was first introduced in .NET 3.5 SP1. Functionality that isn't often needed is removed from the Client Profile. This results in a smaller download and reduced installation time for users. At the time of writing, Microsoft has reduced the size of the Client Profile to around 34MB, although it intends to minimize it even further for the final release.

The .NET 4.0 Client Profile is supported by all environments that support the full .NET Framework, and is redistributable (rather than web download only) and contains improvements to add/remove program entries, unlike the version available in .NET 3.5 SP1.

To use the Client Profile in your application, open the project Properties page, select the Application tab, and on the "Target framework" drop-down menu, select .NET Framework 4.0 Client Profile (as shown in Figure 4-3). Note that in VB.NET, this option is on the Compile Advanced Compile Options tab.

Client profile is the default target framework option in many VS2010 project types, such as Windows Forms and Console. This is important to remember because sometimes you will need functionality not available in the Client Profile and be confused as to why various options are not available in the Add Reference menu.

For more information about the Client Profile, please consult http://blogs.msdn.com/jgoldb/archive/2009/05/27/net-framework-4-client-profile-introduction.aspx.

Figure 4.3. Selecting the Client Profile option

4.1.6. In-Process Side-by-Side Execution

Prior to .NET 4.0, COM components would always run using the latest version of the .NET Framework installed by the user. This could cause some issues; for example, at some of the PDC08 presentations, Microsoft cited an Outlook add-in that contained a thread variable initialization bug. The add-in worked correctly in .NET 1.0, but after the clever guys in the CLR team made performance improvements to the threading pool in .NET 1.1, the add-in left many Microsoft executives unable to read their e-mail (some cynics argued that little productivity was lost).

Obviously, you want to fix this bug, but it is vital to know that your application will run in the same manner as when you tested it. In-process side-by-side execution ensures that COM components run using the version of the framework they were developed for.

Prior to .NET 4.0, COM components would run using the latest version of the .NET Framework installed. You can now force COM components to use a specific framework version by adding the supportedRuntime section to App.config:

<configuration>
  <startup>
    <supportedRuntime version="v4.0.20506" />
  </startup>
</configuration>

You can also force components to use the latest version of the .NET Framework with the following configuration:

<configuration>
   <startup>
      <process>
         <rollForward enabled="true" />
      </process>
   </startup>
</configuration>

For more information, please refer to http://msdn.microsoft.com/en-gb/library/ee518876(VS.100).aspx.

Developers creating .NET components should note that their libraries will always run using the same framework version of the app domain they are running in if loading through a reference or call to Assembly.Load(). For example, libraries built in a previous version of .NET used in an application upgraded to .NET 4.0 will run using .NET 4.0. This might not be the case for unmanaged code, however.