Scenario - Updating Plugins from many parties

Topics: Updater Application Block
Feb 11, 2005 at 5:15 AM
originally posted by: Bern

I have downloaded and built the January drop and I've gotten the QuickStarts to run successfully. I have read the entire UAB V2 doc file, but I am still unclear on a key point or two and I hope someone can clear these things up for me.

I have a large app with many extensibility points and it is extended by many parties. All kinds of plugins can and have been written, and yet, we are adding a brand new extensibilty point that allows 3rd parties (and ourselves) to create a brand new kind of plugin for the app. Plugins of this type have a very particular purpose and the app determines what set of plugins of this type are needed during the early stages of loading a document. The document itself describes the plugins that are required. It may describe plugins that are not yet on the target system, or that are there but are out-of-date. We will maintain a server that all parties may use to store, distribute and update the plugins they've written.

I would like to have one UAB "universe" dedicated soley to updating the application with respect to plugins of this one type. I would like the app to retain the freedom to use UAB for updating other types of things too, but I don't want the configurations or operation to necessarily mix at all. I can imagine a 3rd party, entirely on their own, deciding to employ UAB to make their commercial extension of our app auto-updating and it would have it's own manifest served from it's own site. I don't want to preclude that. I lean heavily toward an in-proc solution since, if every vendor of a desktop app wants to install a service on the users computer then I don't think we'll be making them very happy.

For in-proc controllers the design of the UAB seems to lead to "one .exe, one app.config, one UAB universe". Is it more versatile than that? Can I have more than one UpdaterConfiguration.config file? Or get multiple applicationUpdater config elements some other way? If I can have more than one UAB configuration for a single process, then how do I obtain an ApplicationUpdaterManager instance for a particular one?


Here is another question about the configuration. Obviously various files have varying activation requirements. The key elements of a manifest are ordered and require exactly one occurance. It appears that I cannot have a set of files, then a set of activators, another set of files, another set of different activators, et cetera, in a single manifest file. Does this mean that I must resort to having a separate but included manifest document for each set of activation behaviors that my files require? Can a manifest that is included in a parent manifest also include other manifests itself? If yes, does this entire heirarchy get flattened out into the single array of manifests when it is retrieved? If yes, will that be a depth first or breadth first traversal of the heirarchy?