Microsoft released the .
NET Runtime 4.0 and with it comes a brand spanking new version of ASP.
NET – version 4.0 – which provides an incremental set of improvements to an already powerful platform. .
NET 4.0 is a full release of the .
NET Framework, unlike version 3.5, which was merely a set of library updates on top of the .
NET Framework version 2.0. Because of this full framework revision, there has been a welcome bit of consolidation of assemblies and configuration settings. The full runtime version change to 4.0 also means that you have to explicitly pick version 4.0 of the runtime when you create a new Application Pool in IIS, unlike .
NET 3.5, which actually requires version 2.0 of the runtime.
In this first of two parts I'll take a look at some of the changes in the core ASP.
NET runtime. In the next edition I'll go over improvements in
Web Forms and Visual Studio.
Core Engine Features
Most of the high profile improvements in ASP.
NET have to do with
Web Forms, but there are a few gems in the core runtime that should make life easier for ASP.
NET developers. The following list describes some of the things I've found useful among the new features.
Clean
web.config Files Are Back!
If you've been using ASP.
NET 3.5, you probably have noticed that the
web.config file has turned into quite a mess of configuration settings between all the custom handler and module mappings for the various
web server versions. Part of the reason for this mess is that .
NET 3.5 is a collection of add-on components running on top of the .
NET Runtime 2.0 and so almost all of the new features of .
NET 3.5 where essentially introduced as custom modules and handlers that had to be explicitly configured in the config file. Because the core runtime didn't rev with 3.5, all those configuration options couldn't be moved up to other configuration files in the system chain. With version 4.0 a consolidation was possible, and the result is a much simpler
web.config file by default.
A default empty ASP.
NET 4.0
Web Forms project looks like this:
<?xml
version="1.0"?>
<configuration>
<system.web>
<compilation
debug="true"
targetFramework="4.0" />
</system.web>
</configuration>
Need I say more?
Configuration Transformation Files to Manage Configurations and Application Packaging
ASP.
NET 4.0 introduces the ability to create multi-target configuration files. This means it's possible to create a single configuration file that can be transformed based on relatively simple replacement rules using a Visual Studio and WebDeploy provided XSLT syntax. The idea is that you can create a 'master' configuration file and then create customized versions of this master configuration file by applying some relatively simplistic search and replace, add or remove logic to specific elements and attributes in the original file.
To give you an idea, here's the example code that Visual Studio creates for a default
web.Release.config file, which replaces a connection string, removes the debug attribute and replaces the CustomErrors section:
<?xml
version="1.0"?>
<configuration
xmlns:xdt="http://schemas.
microsoft.com/XML-Document-Transform">
<connectionStrings>
<add
name="MyDB"
connectionString="Data Source=ReleaseSQLServer;Initial
Catalog=MyReleaseDB;Integrated Security=True"
xdt:Transform="SetAttributes"
xdt:Locator="Match(name)"/>
</connectionStrings>
<system.web>
<compilation
xdt:Transform="RemoveAttributes(debug)" />
<customErrors
defaultRedirect="GenericError.htm"
mode="RemoteOnly"
xdt:Transform="Replace">
<error
statusCode="500"
redirect="InternalError.htm"/>
</customErrors>
</system.web>
</configuration>
You can see the XSL transform syntax that drives this functionality. Basically, only the elements listed in the override file are matched and updated – all the rest of the original
web.config file stays intact.
Visual Studio 2010 supports this functionality directly in the project system so it's easy to create and maintain these customized configurations in the project tree. Once you're ready to publish your application, you can then use the Publish <yourWebApplication> option on the Build menu which allows publishing to disk, via FTP or to a
Web Server using
Web Deploy. You can also create a deployment package as a .zip file which can be used by the WebDeploy tool to configure and install the application. You can manually run the
Web Deploy tool or use the IIS Manager to install the package on the server or other machine.
You can find out more about WebDeploy and Packaging here: http://tinyurl.com/2anxcje.
Improved Routing
Routing provides a relatively simple way to create clean URLs with ASP.
NET by associating a template URL path and routing it to a specific ASP.
NET HttpHandler.
Microsoft first introduced routing with ASP.
NET MVC and then they integrated routing with a basic implementation in the core ASP.
NET engine via a separate ASP.
NET routing assembly.
In ASP.
NET 4.0, the process of using routing functionality gets a bit easier. First, routing is now rolled directly into System.
Web, so no extra assembly reference is required in your projects to use routing. The RouteCollection class now includes a MapPageRoute() method that makes it easy to route to any ASP.
NET Page requests without first having to implement an IRouteHandler implementation. It would have been nice if this could have been extended to serve *any* handler implementation, but unfortunately for anything but a Page derived handlers you still will have to implement a custom IRouteHandler implementation.
ASP.
NET Pages now include a RouteData collection that will contain route information. Retrieving route data is now a lot easier by simply using this.RouteData.Values["routeKey"] where the routeKey is the value specified in the route template (i.e., "users/{userId}" would use Values["userId"]).
The Page class also has a GetRouteUrl() method that you can use to create URLs with route data values rather than hardcoding the URL:
<%=
this.GetRouteUrl("users",new { userId="ricks" }) %>
You can also use the new Expression syntax using <%$RouteUrl %> to accomplish something similar, which can be easier to embed into Page or MVC View code:
<a
runat="server"
href='<%$RouteUrl:RouteName=user, id=ricks %>'>Visit User</a>
Finally, the Response object also includes a new RedirectToRoute() method to build a route url for redirection without hardcoding the URL.
Response.RedirectToRoute("users", new { userId = "ricks" });
All of these routines are helpers that have been integrated into the core ASP.
NET engine to make it easier to create routes and retrieve route data, which hopefully will result in more people taking advantage of routing in ASP.
NET.
To find out more about the routing improvements you can check out Dan Maharry's blog which has a couple of nice blog entries on this subject: http://tinyurl.com/37trutj and http://tinyurl.com/39tt5w5.
Session State Improvements
Session state is an often used and abused feature in ASP.
NET and version 4.0 introduces a few enhancements geared towards making session state more efficient and to minimize at least some of the ill effects of overuse. The first improvement affects out of process session state, which is typically used in
web farm environments or for
sites that store application sensitive data that must survive AppDomain restarts (which in my opinion is just about any application). When using OutOfProc session state, ASP.
NET serializes all the data in the session statebag into a blob that gets carried over the network and stored either in the State server or SQL Server via the Session provider.
Version 4.0 provides some improvement in this serialization of the session data by offering an enableCompression option on the
web.Config <Session> section, which forces the serialized session state to be compressed. Depending on the type of data that is being serialized, this compression can reduce the size of the data travelling over the wire by as much as a third. It works best on string data, but can also reduce the size of binary data.
In addition, ASP.
NET 4.0 now offers a way to programmatically turn session state on or off as part of the request processing queue. In prior versions, the only way to specify whether session state is available is by implementing a marker interface on the HTTP handler implementation. In ASP.
NET 4.0, you can now turn session state on and off programmatically via HttpContext.Current.SetSessionStateBehavior() as part of the ASP.
NET module pipeline processing as long as it occurs before the AquireRequestState pipeline event.
Output Cache Provider
Output caching in ASP.
NET has been a very useful but potentially memory intensive feature. The default OutputCache mechanism works through in-memory storage that persists generated output based on various lifetime related parameters. While this works well enough for many intended scenarios, it also can quickly cause runaway memory consumption as the cache fills up and serves many variations of pages on your site.
ASP.
NET 4.0 introduces a provider model for the OutputCache module so it becomes possible to plug-in custom storage strategies for cached pages. One of the goals also appears to be to consolidate some of the different cache storage mechanisms used in .
NET in general to a generic Windows AppFabric framework in the future, so various different mechanisms like OutputCache, the non-Page specific ASP.
NET cache and possibly even session state eventually can use the same caching engine for storage of persisted data both in memory and out of process scenarios.
For developers, the OutputCache provider feature means that you can now extend caching on your own by implementing a custom Cache provider based on the System.
Web.Caching.OutputCacheProvider class. You can find more info on creating an Output Cache provider in Gunnar Peipman's blog at: http://tinyurl.com/2vt6g7l.
Response.RedirectPermanent
ASP.
NET 4.0 includes features to issue a permanent redirect that issues as an HTTP 301 Moved Permanently response rather than the standard 302 Redirect respond. In pre-4.0 versions you had to manually create your permanent redirect by setting the Status and Status code properties – Response.RedirectPermanent() makes this operation more obvious and discoverable. There's also a Response.RedirectToRoutePermanent() which provides permanent redirection of route Urls.
Preloading of
Applications
ASP.
NET 4.0 provides a new feature to preload ASP.
NET applications on startup, which is meant to provide a more consistent startup experience. If your application has a lengthy startup cycle it can appear very slow to serve data to clients while the application is warming up and loading initial resources. So rather than serve these startup requests slowly in ASP.
NET 4.0, you can force the application to initialize itself first before even accepting requests for processing.
This feature works only on IIS 7.5 (Windows 7 and Windows Server 2008 R2) and works in combination with IIS. You can set up a worker process in IIS 7.5 to always be running, which starts the Application Pool worker process immediately. ASP.
NET 4.0 then allows you to specify site-specific settings by setting the serverAutoStartEnabled on a particular site along with an optional serviceAutoStartProvider class that can be used to receive "startup events" when the application starts up. This event in turn can be used to configure the application and optionally pre-load cache data and other information required by the app on startup.
The configuration settings need to be made in applicationhost.config:
<sites>
<site
name="WebApplication2"
id="1">
<application
path="/"
serviceAutoStartEnabled="true"
serviceAutoStartProvider="PreWarmup" />
</site>
</sites>
<serviceAutoStartProviders>
<add
name="PreWarmup"
type="PreWarmupProvider,MyAssembly" />
</serviceAutoStartProviders>
Hooking up a warm up provider is optional so you can omit the provider definition and reference. If you do define it here's what it looks like:
public
class
PreWarmupProvider
System.
Web.Hosting.IProcessHostPreloadClient
{
public
void Preload(string[] parameters)
{
// initialization for app
}
}
This code fires and while it's running, ASP.NET/IIS will hold requests from hitting the pipeline. So until this code completes the application will not start taking requests. The idea is that you can perform any pre-loading of resources and cache values so that the first request will be ready to perform at optimal performance level without lag.
Runtime Performance Improvements
According to
Microsoft, there have also been a number of invisible performance improvements in the internals of the ASP.
NET runtime that should make ASP.
NET 4.0
applications run more efficiently and use less resources. These features come without any change requirements in
applications and are virtually transparent, except that you get the benefits by updating to ASP.
NET 4.0.
Summary
The core feature set changes are minimal which continues a tradition of small incremental changes to the ASP.
NET runtime. ASP.
NET has been proven as a solid platform and I'm actually rather happy to see that most of the effort in this release went into stability, performance and usability improvements rather than a massive amount of new features. The new functionality added in 4.0 is minimal but very useful.
A lot of people are still running pure .
NET 2.0
applications these days and have stayed off of .
NET 3.5 for some time now. I think that version 4.0 with its full .
NET runtime rev and assembly and configuration consolidation will make an attractive platform for developers to update to.
If you're a
Web Forms developer in particular, ASP.
NET 4.0 includes a host of new features in the
Web Forms engine that are significant enough to warrant a quick move to .
NET 4.0. I'll cover those changes in my next column. Until then, I suggest you give ASP.
NET 4.0 a spin and see for yourself how the new features can help you out.
© Rick Strahl, West Wind Technologies, 2005-2010Posted in ASP.NET
