Considering a Generic Application Loader

An application loader is an executable assembly that contains just enough code to request other code from some remote location. The remote location may be an intranet server at your company or a Web site on the other side of the planet. All an application loader has to do is download one root assembly. If this root assembly refers to all other assemblies that your application needs, then when those assemblies are actually needed the root will contain a reference to their location. This reference to other assemblies will cause associated assemblies to be downloaded when the root assembly refers to them. As a result you can permit clients to download a very small application loader (an executable) from a network site, and that loader can play the role of root or request a root assembly. All associated assemblies will be backtracked to the original site and downloaded as needed. You do not need to execute an Assembly.LoadFrom statement for every assembly; just the root will do.

The drawback to this approach is that the application will not run if you are disconnected from the network. As mentioned earlier, a disconnected state will not permit a comparison between cached assemblies and assemblies at the networked location. However, what if it is permissible for the application to run even when the client PC is disconnected, obtaining any updates at a later time when the PC is connected? Under these circumstances you need an application updater that is smarter than the behavior you get from simply executing an Assembly.LoadFrom call. This scenario describes the behavior of the Terrarium game. Terrarium attempts to update assemblies when the application runs but falls back to current assemblies in the event that the PC is disconnected.

There is probably no specific definition of a single application loader. The general idea is that updates downloaded from the Internet are managed invisibly and conveniently to prevent a disconnected state from halting an application. The Terrarium game, for example, is downloaded and installed like a traditional application with all its assemblies in place. Then these assemblies are downloaded and updated at the convenience of the connection state of the individual PC. This reflects a hybrid of traditional download and install behavior and smart client updates. It seems highly feasible that a root assembly could be downloaded and all assemblies copied at that point in time, followed by smart updates based on the connected state of the PC. Perhaps a generic commercial application updater will be made and sold just as installation utilities were made and sold in the last ten years. Such a generic application updater will need to consider disconnected states, version rollbacks, and evolving security policies to support the greatest number of consumer applications. Until a general, commercial product exists, each vendor will have to solve this predicament on a case-by-case basis.