What is new in ASP.Net 4.0 Part-3

Object Caching and Object Caching Extensibility

Since its first release, ASP.NET has included a powerful in-memory object cache (System.Web.Caching.Cache). The cache implementation has been so popular that it has been used in non-Web applications. However, it is awkward for a Windows Forms or WPF application to include a reference to System.Web.dll just to be able to use the ASP.NET object cache.

To make caching available for all applications, the .NET Framework 4 introduces a new assembly, a new namespace, some base types, and a concrete caching implementation. The new System.Runtime.Caching.dll assembly contains a new caching API in the System.Runtime.Caching namespace. The namespace contains two core sets of classes:

• Abstract types that provide the foundation for building any type of custom cache implementation.
• A concrete in-memory object cache implementation (the System.Runtime.Caching.MemoryCache class).

The new MemoryCache class is modeled closely on the ASP.NET cache, and it shares much of the internal cache engine logic with ASP.NET. Although the public caching APIs in System.Runtime.Caching have been updated to support development of custom caches, if you have used the ASP.NET Cache object, you will find familiar concepts in the new APIs.

An in-depth discussion of the new MemoryCache class and supporting base APIs would require an entire document. However, the following example gives you an idea of how the new cache API works. The example was written for a Windows Forms application, without any dependency on System.Web.dll.

 private void btnGet_Click(object sender, EventArgs e) 
{ 
  //Obtain a reference to the default MemoryCache instance. 
  //Note that you can create multiple MemoryCache(s) inside 
  //of a single application. 
  ObjectCache cache = MemoryCache.Default; 
  
  //In this example the cache is storing the contents of a file string 
  fileContents = cache["filecontents"] as string;
  
  //If the file contents are not currently in the cache, then 
  //the contents are read from disk and placed in the cache. 
  if (fileContents == null) 
  {
    //A CacheItemPolicy object holds all the pieces of cache 
    //dependency and cache expiration metadata related to a single 
    //cache entry. 
    CacheItemPolicy policy = new CacheItemPolicy(); 
    
    //Build up the information necessary to create a file dependency. 
    //In this case we just need the file path of the file on disk. 
    List filePaths = new List(); 
    filePaths.Add("c:\\data.txt"); 
    
    //In the new cache API, dependencies are called "change monitors". 
    //For this example we want the cache entry to be automatically expired 
    //if the contents on disk change. A HostFileChangeMonitor provides 
    //this functionality. 
    policy.ChangeMonitors.Add(new HostFileChangeMonitor(filePaths)); 
    
    //Fetch the file's contents 
    fileContents = File.ReadAllText("c:\\data.txt"); 
    
    //And then store the file's contents in the cache 
    cache.Set("filecontents", fileContents, policy); 
    
  } 
  MessageBox.Show(fileContents); 
} 

Extensible HTML, URL, and HTTP Header Encoding

In ASP.NET 4, you can create custom encoding routines for the following common text-encoding tasks:

• HTML encoding.
• URL encoding.
• HTML attribute encoding.
• Encoding outbound HTTP headers.

You can create a custom encoder by deriving from the new System.Web.Util.HttpEncoder type and then configuring ASP.NET to use the custom type in the httpRuntime section of the Web.config file, as shown in the
following example:

 <httpRuntime encoderType="Samples.MyCustomEncoder, Samples" /> 

After a custom encoder has been configured, ASP.NET automatically calls the custom encoding implementation whenever public encoding methods of the System.Web.HttpUtility or System.Web.HttpServerUtility classes are called. This lets one part of a Web development team create a custom encoder that implements aggressive character encoding, while the rest of the Web development team continues to use the public ASP.NET encoding APIs. By centrally configuring a custom encoder in the httpRuntime element, you are guaranteed that all text-encoding calls from the public ASP.NET encoding APIs are routed through the custom encoder.

Performance Monitoring for Individual Applications in a Single Worker Process

In order to increase the number of Web sites that can be hosted on a single server, many hosters run multiple ASP.NET applications in a single worker process. However, if multiple applications use a single shared worker process, it is difficult for server administrators to identify an individual application that is experiencing problems.

ASP.NET 4 leverages new resource-monitoring functionality introduced by the CLR. To enable this functionality, you can add the following XML configuration snippet to the aspnet.config configuration file.

 <?xml version="1.0" encoding="UTF-8" ?> 
<configuration> 
  <runtime> 
    <appDomainResourceMonitoring enabled="true"/> 
  </runtime> 

</configuration>

Note The aspnet.config file is in the directory where the .NET Framework is installed. It is not the Web.config file.

When the appDomainResourceMonitoring feature has been enabled, two new performance counters are available in the “ASP.NET Applications” performance category: % Managed Processor Time and Managed Memory Used. Both of these performance counters use the new CLR application-domain resource management feature to track estimated CPU time and managed memory utilization of individual ASP.NET applications. As a result, with ASP.NET 4, administrators now have a more granular view into the resource consumption of individual applications running in a single worker process.

Multi-Targeting

You can create an application that targets a specific version of the .NET Framework. In ASP.NET 4, a new attribute in the compilation element of the Web.config file lets you target the .NET Framework 4 and later. If you explicitly target the .NET Framework 4, and if you include optional elements in the Web.config file such as the entries for system.codedom, these elements must be correct for the .NET Framework 4. (If you do not explicitly target the .NET Framework 4, the target framework is inferred from the lack of an entry in the Web.config file.)

The following example shows the use of the targetFramework attribute in the compilation element of the Web.config file.

<compilation targetFramework=”4.0″/>

Note the following about targeting a specific version of the .NET Framework:

• In a .NET Framework 4 application pool, the ASP.NET build system assumes the .NET Framework 4 as a target if the Web.config file does not include the targetFramework attribute or if the Web.config file is missing. (You might have to make coding changes to your application to make it run under the .NET Framework 4.)
• If you do include the targetFramework attribute, and if the system.codeDom element is defined in the Web.config file, this file must contain the correct entries for the .NET Framework 4.
• If you are using the aspnet_compiler command to precompile your application (such as in a build environment), you must use the correct version of the aspnet_compiler command for the target framework. Use the compiler that shipped with the .NET Framework 2.0 (%WINDIR%\Microsoft.NET\Framework\v2.0.50727) to compile for the .NET Framework 3.5 and earlier versions. Use the compiler that ships with the .NET Framework 4 to compile applications created using that framework or using later versions.
• At run time, the compiler uses the latest framework assemblies that are installed on the computer (and therefore in the GAC). If an update is made later to the framework (for example, a hypothetical version 4.1 is installed), you will be able to use features in the newer version of the framework even though the targetFramework attribute targets a lower version (such as 4.0). (However, at design time in Visual Studio 2010 or when you use the aspnet_compiler command, using newer features of the framework will cause compiler errors).