Configuring ASP.NET

In last month’s column, I looked at .NET assemblies. I explained what they are, why they matter and what you can do with them. I illustrated the key concepts by using some simple bits of basic C# code, the tools supplied with the .NET 2 Framework and the .NET 2 Framework SDK. I’d intended this month to provide more details on assemblies, looking at deployment and how to manage assemblies in an enterprise environment. However, I first want to finish off the story of the .NET Framework itself, as I haven’t yet mentioned one important aspect of it: ASP.NET.

So, I’m going to examine ASP.NET and the underpinnings of web apps: the Hyper Text Transfer Protocol (HTTP) and Microsoft’s Internet Information Server (IIS). I’ll describe what ASP.NET is, how it works and how to manage and configure it. I’ll also be looking at how to configure both IIS and ASP.NET apps via web.config and machine.config files.

Web Applications

A web app is different from a .NET Windows app as described in the last column, a key difference being that your Windows app has to first be deployed onto a client and then runs in the client hardware environment. Some client apps will make use of server-side processing, using mechanisms such as Remote Procedure Call (RPC), but the main client app runs on the client machine where it has to be deployed, updated and managed. With a web app, however, the only code the client needs to run is a web browser compatible with the app in question. Most often, any web browser will do, but in far too many cases a particular browser is required, such as Internet Explorer, to support ActiveX controls.

Perhaps the most important aspect of a web app is that it’s server based and can be managed from the server – even where the web app offloads some processing to the client via JavaScript or ActiveX controls, that client-side code is still server controlled. This means you can update a web app (to fix a bug or add features) entirely at the server, so the next time a user accesses the app they’ll receive the updated version. Web apps hence avoid many of the headaches involved in deploying and maintaining rich-client apps on a large number of client PCs.

HTTP Protocol

Web apps use HTTP as the underlying protocol for communicating between the client and server components of the app. Firewall admins will be familiar with HTTP as being the ‘universal firewall bypass protocol’, but HTTP is essential to web app designers because of the large range of features it provides, like the ability to send both read and write requests to a web server and support for forms (and it tends not to be blocked by pesky firewalls).

While HTTP is a most useful protocol, its employment for web apps does involve a small but important design problem, due to the fact it’s a stateless protocol, unlike rival protocols such as CIFS. The TCP/IP experts among you will know that HTTP is implemented on top of TCP – which, of course, is stateful – but while the transmission of an HTTP request or response relies on an underlying stateful transmission protocol, HTTP itself is nevertheless stateless: after an HTTP server has processed a client request, it retains no memory of anything about the request or the client. This means either that the web app, or its underlying environment, needs to supply some mechanism for remembering state across individual transactions.

Being stateless does confer one important advantage, though, as it lets HTTP-based web apps scale very linearly onto large server farms, with hardware or software load balancing. This approach works well for static or simple web apps, and even more complex apps may scale well if you do some work with respect to state management. This means you can implement a web app on a small single server and then scale up to a large parallel array of multiprocessor systems relatively easily, all without any impact on the client systems.