Many install programs are designed to offer the user different installation options and this may lead to different executables being deployed to a given machine. Lets say you have an install program that offers the user an optional extra component. If the main component consistes of two executables and a few dll files and the optional extra component contains another exe and a couple more dlls.
Eg.
Feature A:app1.exeapp2.exedll1.dlldll2.dlldll3.dll
Feature B:app3.exedll4.dlldll5.dll
The user runs the main install program and can choose either Feature A or Feature B or both.
Now the BIG question is how should we deal with updates for this using wybuild/wyupdate?
Background:I will be deploying several windows services which run unattended and have unattended automatic upgrades run. Currently I have had to structure the install program so that regardless of what options are chosen by the user all files are actually deployed. When running an upgrade I know what options were originally chosen by the user and therefore only restart the appropriate services. However it would be MUCH simpler if I could avoid deploying and updating files that are not needed for particular install configurations. I cant treat these components truly as separate applications as they all need upgrading at the same time (sharing some common dlls means all services must be stopped at the same time). If an infrequently used install option has a particularly large file size payload or if it contained 3rd party code for which an additional license fee was due then physically deploying all files regardless of user install options might not be a very practical approach.
However it would be MUCH simpler if I could avoid deploying and updating files that are not needed for particular install configurations.
As of wyBuild 2.6.x, we currently don't have the ability to have modular (or partial) updates. We realize this is a simplistic view of products and we'll be adding modular updating ability to wyBuild 2.7.x (sometime after 2.7.0).
GuestFor the application I have just developed (a set of 3 applications) truly modular updates would be highly desirable. The application is deployed on ships worldwide and update patches ultimately have to come over a slow VSAT connection. Deploying unneeded files is highly undesirable. Its also inconvenient to stop a system that is designed to run 24/7 in order to run an upgrade. This cannot be avoided but stopping it for longer than needed because we are updating a large file that is actually unneeded (part of an optional extra) is just plain wrong!
For my problems I decided to deploy all files to work around this deficiency in wybuild. I just about works for this simple data logger project. I have larger and much more sophisticated installations with many optional extra modules. These installations are currently highly unsuitable for use with wybuild/wyupdate due to the number of optional modules installed.
These are my ideas...
My feeling is that modular updates might be accomplished in wybuild by specifying a unique "group" name on a per file basis. Other than the default "group" - what we have currently. The user could specify additional group names to be associated with sets of files added for a particular version. If wybuild could essentially treat files belonging to different groups as different products and build separate update files for each group. Groups could also be associated with update actions (starting and stopping services and any future actions that may become part of wybuild.
A deployed product needs a way of telling wyupdate which groups to update. I'm happy if this is a command line switch to wyupdate. But any other means is acceptable as long as its something that can be determined at installation time. Essentially then wyupdate can download updates as required for the specified groups. They can all be applied in one go. This approach would minimize network bandwidth.
Talking of minimizing network bandwidth. I'd ideally like to be able tell wyupdate to place a copy of the downloaded on a local folder or network share. This way other machines on the ship can first check a local cached copy before hitting the internet.
I'd be interested in hearing your ideas regarding the implementation of modular updates in a future wybuild/wyupdate release and am willing to help and review the specification.
Best regards,Dave HusseyNAVSYSTEMS (IOM) LIMITED
The application is deployed on ships worldwide and update patches ultimately have to come over a slow VSAT connection. Deploying unneeded files is highly undesirable. Its also inconvenient to stop a system that is designed to run 24/7 in order to run an upgrade. This cannot be avoided but stopping it for longer than needed because we are updating a large file that is actually unneeded (part of an optional extra) is just plain wrong!
Sure, I understand. We're working on this modular updates system for customers like you.
There a couple of hacky ways you can do it with wyBuild 2.6.x. One way is to have a separate wyBuild project for each module. Then update the modules separately. (I can explain this in detail if you want). The downside is that you have to update the modules separately instead of as a whole product.
My feeling is that modular updates might be accomplished in wybuild by specifying a unique "group" name on a per file basis. Other than the default "group" - what we have currently. The user could specify additional group names to be associated with sets of files added for a particular version. If wybuild could essentially treat files belonging to different groups as different products and build separate update files for each group. Groups could also be associated with update actions (starting and stopping services and any future actions that may become part of wybuild.
That's basically how it will work in wyBuild 2.7. The modules will essentially be separate update files that wyUpdate will download based on the installed features.
A deployed product needs a way of telling wyupdate which groups to update. I'm happy if this is a command line switch to wyupdate. But any other means is acceptable as long as its something that can be determined at installation time. Essentially then wyupdate can download updates as required for the specified groups. They can all be applied in one go. This approach would minimize network bandwidth.
That's how it's currently implemented in our pre-beta version of wyUpdate 2.7. We're considering whether to check for registry values as well.
Talking of minimizing network bandwidth. I'd ideally like to be able tell wyupdate to place a copy of the downloaded on a local folder or network share. This way other machines on the ship can first check a local cached copy before hitting the internet.
You can do that using the %updatepath% variable.
