Prior to including this application block as part of your enterprise architecture, do check out the architectural alternative of push technology, using Systems Management Server or group policy of active directory. Apart from server cost this may turn out to be information overload, but provides lot of benefits with simplified application deployment and administration, like ability to rollout to specific group, incremental updates greatly reducing network traffic and reduces the operational costs of developing software for deployment.
We can also look at another technical alternative that is shipped with .NET 1.0, HREF-EXE AKA Zero-touch deployment {sounds very similar to JAVA Web Start ;-)}. It might turn to be simplest of all deployment models, you deploy the application in any web server and user clicks on the link to the application .NET downloads the application and executes it. The update mechanism is like updating web applications, simply have to replace the file on the Web server and from that point on everyone launching your application will get the newest version.
But HREF-EXE come with an inherent limitations like, No offline support (always connected to web server), No desktop integration (user has to manually create an shortcut to exe), Runs in a sandbox with restricted semi-trust security (will not be able to call a web service in different machine from where exe is downloaded) and network delay (fat smart client apps will be more impacted).
Some of these limitations are overcome in next generation of this technology, ClickOnce shipping with .NET 2.0, with features like offline support, rolling back to previous versions of an application, and listing an application in the Windows Start menu & Add/Remove Programs catalog, HTTP compression support, simpler deployment packaging with help of "Whidbey". But if you are looking at capabilities like install to GAC, manage ODBC or COM+, registry write, setting up permissions (File/Folder/Registry) or any custom actions at install/uninstall, Install On Demand
Transactional Installation and Source Resiliency, only option is MSI.
The Updater Application Block helps to detect, validate, and download application updates deployed in a central location, using a "pull" model, with minimal coding and ability to configure externally and extend it for any special reqt.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/updater.asp
1. All applications will have a boot strap application (AppStart.exe) which will use its configuration file to identify the latest and greatest version of the application and launch it.
2. The Updater Application Block requires a controller application to start/stop the update process and handle the various events that occur when application update tasks are performed. There are three distinct types of controller, each with their own considerations: Computer-Wide Controllers, Application Launcher Controllers and Self-Updating Applications. This controller app will get the server manifest for the application, connecting to the web server and check if there is any updated version available.
3. If new version is found, it will download the latest version using an downloader (Background intelligent transfer service (BITS) downloader comes out-of-the-box)
4. Uses and validates binaries (basically an crypto hash check with RSA algorithm) to ensure authenticity of the binaries
5. Updates the boot strap application configuration to the new version and runs the post-installation tasks if specified in manifest.
6. Depending on the type of controller, the new version is launched, if its a self updating controller, all the update happens in background and application gets notified of the successful completion of updating, which can take action like popping up a form to confirm with user on launching updated version.
As with other application blocks everything is customizable and out-of-the-box ships with a standard binaries that can be used for 90% of cases. Its one of the simpler and easy to use blocks of what i have seen. There is no sample provided for Application Launcher Controllers, although it should be easier to modify application launcher to make the asynchronous update process as a synchronous one, i got a very good sample for this one from Chris L. Kinsman http://www.vergentsoftware.com/downloads/uabsamples.zip.
Some of the features that i wish/expect to be in next release,
- Make mandatory updates, in most of cases you might want to make the update mandatory instead of user opting for an update
- Incremental update, i would prefer to publish only modified binaries and application block should be able to take the other files from the previous version of application
- Manage staged rollouts, to be able to control which clients update and when. Found a simple and good solution in net, modify the manifest retrieval code so that it can call an ASP.NET page, which returns different manifests based on the user's credentials (so you can have a group of users who are given one version, and everyone else gets the last major release or a one department can be given one version that is different from another department)
- Compression on the wire, this will help reduce a lot of network traffic
- Rollback update, only way to do that out-of-the-box is to release a new version with older binaries, works perfect but may be we can do that better
- Cleanup old versions, which should be simpler with some code in post processor
- May be i'm more user friendly, i would like to have a "what's new" or more accurately "what's the fix" information for the updated version to be available in manifest
The soon be released Updater Application Block 2.0, focuses on simplification of use, adherence to the Enterprise Library specification, and alignment with .NET 2.0 ClickOnce.
Saturday, February 26, 2005
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment