RFC: Extending a Deployed Smart Client Application

Topics: CAB & Smart Client Software Factory
Jan 27, 2006 at 10:39 AM
originally posted by: PProvost

This is the third RFC (Request for Comments) thread. The idea of these threads, as the name implies, is to get your input on a specific topic or problem that we are considering addressing.

The topic of this RFC is Extending a Deployed Smart Client Application. By this we mean something like this: the ability to add new functionality to a deployed client application without redeploying any of the already deployed components.

1. What are the scenarios where you see this as a necessary capability? Please try to answer the following question in the context of these scenarios.

2. Assuming a restart is required
- Should the application detect this need and advice the user to restart?
- Should the application force the restart (possibly giving the user some time to complete his work)?
- You just wait until the next restart happens.

3. What level of extensibility is required? What kinds of extensions can you envision needing (e.g. new services, new modules, new work-items, extending existing work-items, other)?
Jan 27, 2006 at 10:48 AM
originally posted by: dallasreb

I'll give a description of how we handle auto-updating a current enterprise smart client application.

At startup, the application requests from a web service a client manifest detailing what assemblies should be installed at this time. Note that the client passes the system name and that is used to determine the proper release. We can deploy different releases to different systems allowing beta installation and even rollback (not just latest).

The manifest is used to compare current installed assemblies (everything is local installed not in the GAC) and determine if update is needed. If so, it defers to the autoupgrade program to pull the new assemblies and restart the application. We are using a modified version of the DevX AutoUpgrade project.

As this is an enterprise application, the user does not have the ability to choose not to upgrade. We also do not look for upgrades after the application is running - only at startup.

I can see us updating any extension and even the main shell so everything should be upgradable.
Jan 28, 2006 at 12:33 PM
originally posted by: dfoderick

Hi Peter.

1. I am considering a scenario for deploying modules on a "pay-for-functionality" basis, aka application service provider model. So on startup during authentiction the cab app "phones home" and downloads modules according to the user's subscription level.

2. I see the detection and download happening sometime during the cab app startup process. Advising user to restart to get additional functionality is acceptable but dynamic download and "instantly" plugging in the new functionality would be best. Definitely user needs to be aware of everything that is going on (to minimize customer service calls) but they need to be in control of the process too.

3. WRT extensibility, everything might need to be extended. services, work items, ui workflow.

I'm still fleshing this all out but thanks for listening.
Jan 28, 2006 at 12:57 PM
originally posted by: BradWilsonMSFT

I suspect Peter's question was more about extending an already long-running application, as opposed to making startup decisions.

CAB can support your scenario. You would replace the module enumerator with one that contacts the web service, downloads the appropriate modules, deletes the ones that don't belong any more, etc., and finally handing off the final module list to the module loader service.
Jan 29, 2006 at 6:53 PM
originally posted by: DarrelMiller

My opinion is that adding new functionality without redeployment of existing components is overkill. However, my opinion is only based on the requirements I run into developing a packaged ERP application. We are currently converting our large VB6 application to .Net using CAB.
I am curious to hear why it might be important to others...
Feb 3, 2006 at 8:15 PM
originally posted by: headlam

Deploying and adding new functionality to an already deployed application, without redeploying assemblies that have already been deployed, is a good thing as this would be less taxing on the network. However, ClickOnce already has this capability (yes in some advanced cases you have to get your hands dirty with some coding). Also, since CAB already gives me the ability to load a module on demand and create my own module enumerator I’m not sure what else is being asked here. If via a GAT package we can make this easier I’m all for it providing we understand the security implications.

If on the other hand this is talking about the ability to unload a module and replace it with another module, then that’s different scenario and one that I use to be interested in. In the past I felt this was really a requirement, but I’m not sure anymore – especially with the inherent security risks.

If the discussion is about updating a running application; it would depend on the application and the scenario. In the case where a user is working with a customer on say an order request extending the applications capabilities dynamically (i.e., while it running) is interesting, but might be very risky. Interrupting the users workflow to ask if they want an update is also risky as the customer might be present with the user and or it impacts the workflow negatively (every second counts). So in the end this sounds like a really great developer feature, but I’m not sure how useful it will be for the user/business.