Traditional Deployment Problems and .NET Solutions

In Chapter 2, you learned how .NET solves the infamous component registration problem, allowing DLL files to be freely copied and used without requiring a separate registration tool (such as regsvr32) or a dedicated setup program. Even better, .NET DLLs can be used from local application directories. A central component repository is available the global assembly cache (GAC) but you'll rarely need to use it.

This shift returns programmers to a deployment model similar to the early Windows world. It also gives developers fine-grained control over all the components (and component versions) an application uses. Taken together, these innovations erase the worst nightmares of DLL Hell. They make application updates effortless almost.

The only remaining problem is that someone still needs to perform the actual file copying. If you're deploying a component to a directory on a server, this step might require only a single step; if you need to distribute an application update to remote clients, however, life isn't as easy.

A good example is a "partly disconnected" system. This is the type of system in which some clients need to be disconnected for some of the time, often because they are using a notebook computer and a network/Internet connection is either not available or not of sufficiently high bandwidth. These clients need to work with a dedicated client application that records information locally and then submits it to the central system when the client reconnects. (We examined this model, and the role disconnected clients play in a distributed system, in Chapter 10.)

In a disconnected system, managing updates can be an extremely tedious, time-consuming, and expensive process. Possible approaches include distributing setup CDs, providing downloadable patches, and e-mailing update notifications. And it's even harder to ensure that clients with the wrong versions can't connect to your XML Web services or interact with your remote components. This version mismatch (for example, old-version clients accessing updated server-side components) can introduce all kinds of compatibility problems unless your system design is carefully controlled.

This chapter considers two basic designs for automated deployment:

• An application launcher that examines the current version of an application and can update it (or recommend an update) automatically. This approach completely removes distribution headaches.

• A modular application that downloads just the required portions of an application. This approach won't work for disconnected clients, but it guarantees that remote clients use the most up-to-date version without ever needing to run an installation. It also allows you to tailor the client application to suit different types of users.

We'll also consider how to make these approaches work in a practical setting and avoid the problems that can occur with code access security.