View Full Version : Alternatives to Dynamic File Linking?

11-07-2005, 09:41 PM
I have been working on identifying a reasonable mechanism for producing patches to an existing application. The application uses ASP.NET, and its install payload has a large hierarchy of over 300 directories containing a total of over 3200 files. The install uses a dynamic file link to include this entire hierarchy as it is just too much to manually create components for each target directory, not to mention one component per file to be installed. BUT, use of dynamic file links impose very significant limitations on the ability to produce patches bigger than a Quick Patch and smaller than a Major Upgrade. Thus my question.

Has anyone out there developed a viable alternative to the two options I've mentioned thus far: manually creating all the needed components; and using dynamic file linking?

I've been thinking there is great potential to use the COM Automation interface to write a tool that handles the component "management" that Dynamic File Linking SHOULD be doing rather than the very limiting function it does exhibit. Specifically, the tool should scan a specified subtree against the install project. For those cases where the project contains a directory that does not exist in the input tree, that component can be deleted from the project. Cases where a new directory is encountered cause a new component to be added to the project. But, here is the big piece... the tool keeps the GUID associated with the component in the directory (while exluding it from the files included in the install). Thus, it is possible to associate the same GUID with a given directory so long as that directory remains in the project. New directories get a new GUID assigned, and preserved via this GUID file mechanism.

As far as I can tell, this approach would ensure patching will always be able to address every directory in the application if this technique is applied?

Of course, why limit oneself to a single component per directory? How about going finer grain, say one file per component. That way every file is the key file and can be individually updated via the installer with all catagories of update, right?

I would ask, though, what should be considered the limit on the propagation of components in a product? Where is the tipping point when trading off fine-granularity of patching against the overhead incurred by going with such fine granularity?