Always Update Certain Files

[NickT]

I have been using VP for a few months, and one issue that has come up is that as you add additional versions, the patch file grows larger and takes longer to build. We have noticed that regardless of which version the end user has installed, we always want a core group of DLLs and one EXE file to be replaced with the most current version, and also verify that a few other files are installed to various places. Is there a way to do this easily with VP so that I don't have to create a new version every time we make a change? If I select ever version in the build settings, it takes a really long time, and all I want it to do is just replace a few files with newer ones.

Is this even possible with VP or does it always work off of diffs?

thanks!

[Steven Carr]

I don't think you can effectively get away with not creating a new "version" every time you do an update as there has to be someway to know which "version" is currently installed and what "version" you are patching to.

There is a way to always install a file "Force Install" - From the help file:

Whether or not to force Visual Patch to install the file. This means that if a file with the same name exists in the destination, it will be overwritten. If the file does not exist, it will install it.

Note: Checking this option means that the full copy of this file will be included in the patch.

This setting should help you do what you need to - but if you use this setting liberally then your patch is going to grow in size while you make less and less use of VPs patching engine.

If you can make use of VPs #VERSIONTABNAME# macro as part of the local folder name then you can minimise the manual changes required create a new patch update.

The procedure for me to create a new patch update is "Duplicate Tab"m "Rename Tab" and then "Build". cannot get simplier than this.

But you do need to have your install files organised and an effective method for determining the version.

From your question however it sound a little like you might be trying to just install some files on your system. Personally i would not use VP for this situation and make use of SetupFactory. The main reason is the automatic "determine what version you are using" process will get in the way of just update the files regardless process.

Hope this helps.

[NickT]

Steve, Thanks for the reply. Currently I am creating a new tab, and then dropping in the files that need to be included in that build. I have sub folders with all the files that changed across each version stored on my hard drive. My main problem with this is that if I continue to add patches, the file will continue to grow quite large.
I may look into deploying a setup factory type "patch" because I basically am just over writing the same files to do the patch, regardless of their version.
Thanks!

If anyone else has other suggestions, please let me know.

[Steven Carr]

When you look at it you have to expect the file to grow until it is comparable to the equivalent installer size if you are modifying all of the files in your installation with each update. VP will give you the benefit of verifying your current installation.

VP is smart enough to know when the accumaltive patches are bigger than the equivalent complete file size. If you look at the logs you can see it doing this work.

Before VPs binary patching was introduced I used to pack the EXEs with AsPack. Now i have removed this - the big reason is that any changes to the program then the binary patch will be a lot smaller - where the AsPack versions will almost always need the full file to be included. I suppose i am saying that you can cometime help the patching mechanism or work against it.

Why is the reason that these files are being overwritten all the time? Are they always updated or are they modified at the client end and need to be reset?

[AdrianS]

We have a similar scenario where we want to have two patch files: one that will only patch from the latest version and another that will "patch" from any installed version. The single version patch has the advantage of a minimum file size. The "Any" version patch uses force installs for all of the files, so no diffs are created. The "Any" patch could have also been done with a setup, but we want to have the same look and feel for both patches.

To accomplish this I created a second tab for the "Any" patch that lists all of the files to be patched and has each file set for "Force install". I used this approach because I could find no way to conditionally force install the files. I also have separate build configurations for the single and "Any" patches. The "Any" configuration only includes the first and last versions of our software. The OnStartup script uses different techniques to determine whether the patch can continue based on which build configuration is used. The single configuration uses the standard VP approach and the "Any" configuration just checks for a valid existing installation.

It would likely have also been possible to have each file listed twice on a version tab and have different Build Configuration settings for each file, but I opted not to use that approach because the file list became too cumbersome. If VP had a way of conditionally forcing installs during the build process, the second tab could be eliminated. Also, a highlight colour or column to indicate which files have Force install set would be handy.

[Steven Carr]

AdrianS, have you put your suggestions in the correct area. IR are pretty good with helping out where/when they can.

The Force Install was implemented as a request.

[Lorne]

We have a similar scenario where we want to have two patch files: one that will only patch from the latest version and another that will "patch" from any installed version. The single version patch has the advantage of a minimum file size. The "Any" version patch uses force installs for all of the files, so no diffs are created. The "Any" patch could have also been done with a setup, but we want to have the same look and feel for both patches.

To accomplish this I created a second tab for the "Any" patch that lists all of the files to be patched and has each file set for "Force install". I used this approach because I could find no way to conditionally force install the files. I also have separate build configurations for the single and "Any" patches. The "Any" configuration only includes the first and last versions of our software. The OnStartup script uses different techniques to determine whether the patch can continue based on which build configuration is used. The single configuration uses the standard VP approach and the "Any" configuration just checks for a valid existing installation.

That would work. I'm curious why you need to use "Force install" for this at all, though? Assuming you have one tab for each version, then all you need to do to get the same effect is to select all of the versions when you build the patch.

Note that using "Force install" may cause files to be included and installed even if they haven't changed. It's also quite possible for the binary patching approach to still be smaller than the whole file even across many versions.

As Steven Carr pointed out, Visual Patch automatically includes the whole file as soon as the cumulative size of the binary diffs reaches the zipped size of the whole file. Even with the default settings it should never make a patch that is larger than an equivalent installer.

It would likely have also been possible to have each file listed twice on a version tab and have different Build Configuration settings for each file, but I opted not to use that approach because the file list became too cumbersome.

I would suggest using 2 tabs, one for each build configuration.

If VP had a way of conditionally forcing installs during the build process, the second tab could be eliminated.

The "Force install" option isn't really meant to be used conditionally. As I explained above, VP will already make the decision to include the whole file as soon as it makes sense to do so. (In other words, that condition is already built in.) The recommended approach is to create a tab for each version, and let Visual Patch determine when to include the whole file in the patch.

If for some reason you don't want to create a tab for each version--maybe you put out versions hourly and don't want a project with a gazillion tabs in it --then your approach using "Force install" makes sense, and should work fine.

Also, a highlight colour or column to indicate which files have Force install set would be handy.

That's a good idea. I've logged it as a suggestion. REF#: 12593

In the meantime, you could put a fake script condition on those files, and then show the Script Condition column to spot 'em. Something like this would work:

forced == nil;

(Any unused variable name should resolve to nil.)

Or, if you prefer, you could put "forced = True;" in your startup script, and then just put the word "forced" in as the script condition.

[AdrianS]

The releases of our application total about 25 versions. We wanted a patch that could update most installations even if files are missing or corrupted. I chose the force install route instead of the diff (which would have switched to a force anyhow) in order to avoid having a tab for every version.

I would suggest using 2 tabs, one for each build configuration

That's the approach I'm using. It works OK, however conditional forced installs would eliminate the need for the second tab.

It's not really an issue in our case, but another reason to force an install might be if you need to enforce the date on some files. As I noted in another thread, it appears that files patched with a diff get a modification date set to the execution time of the patch, whereas force installed files get the original file's modification date. That behaviour is consistent with what one would expect from Windows, but in some cases it may cause confusion. I haven't yet found a convenient way to circumvent it.

[Steven Carr]

The releases of our application total about 25 versions. We wanted a patch that could update most installations even if files are missing or corrupted.

Just of interest here. What are your motivations behind trying to combine all the patches this way. Is it the time to maintain (edit) the patches for each new version? Is it the time to create/build each set of patches? Is it the server space to store the patches?

I have a number of patches for the same product but across 10 differernt configurations. We do use seperate patches for each configuration. I dare say that my application if far less complicated than yours - but i would be interested to know your reasons for travelling down this path.

[AdrianS]

Because we have so many versions released (each with about 14 files), any patch that would work for all of them would use full installs anyway. We find that it typically takes about 5 versions for the diffs to switch to full installs. We decided to have just two patch files for our app: one that goes from the second latest version to the latest and one that will patch any version. This reduces the number of files that we have to maintain. More importantly, it makes it easier for the end user to choose the correct patch file. (We do use TrueUpdate, which could easily choose the correct file from many files, but some users resist using it.)

For us, this two patch (three actually, including Betas) approach provides a way to get the patches that we want without having to have tabs for all of our versions. In fact, I've culled some of the older tabs out to reduce clutter. This also helps with the load times for the vp2 files and with build times. The only minor irritation is the second tab that's required.

[Steven Carr]

and one that will patch any version.

Why not use SetupFactory for this? That would mean you don't have all the tabs etc..

The app we use here is across about 10 but it has been as high as 14 configurations. There are 50% files that are different for each configuration.

We use TrueUpdate to decide whether to download the update or full install. These are downloaded as zip files, then extracted and run. Links are given out to the equivalent full installs. Patches are down for the last couple of (monthly) updates at least.

Because i make heavy use of constants the building of installs / patches / true update files only takes a minutes or so for each version.

I would only use VP (over SF) to do a "full install" to take advantage of its ability to verify the current installation but it seems like you are trying to get around this anyway.

[AdrianS]

For historic reasons, we don't use SetupFactory. In actual fact, we have three files for a given version: the full install, a single version patch and the full patch. We could have done the full patch as a separate install (and we have in the past), but we opted to use a patch so that the user look and feel are the same for the two patches.

Because i make heavy use of constants the building of installs / patches / true update files only takes a minutes or so for each version.

That's what we do as well. That's why the conditional forced install would be so helpful.

These are downloaded as zip files, then extracted and run.

By coincidence, see the suggestion that I just posted.

[NickT]

Still Confused

VP seems to not install some of the files that are listed on previous revision tabs.
This is how I am using VP:
After I created an installer with SetupFactory, I made the first tab in VP. I included the exe file (as they key file) and a few supporting dlls.
Later, we fixed a few bugs, so I made a new tab, included the updated exe (again, as the key file) and dlls, and also included a jpg file (marked as "force install") that I needed to install in the users document folder.
Everything seemed great, it installed just fine.
Well, a few more bug fixes later and it was time for another patch, so I made another tab, and added the newest exe (marked as the key file) and dll files and built the patch. Only, it doesn't seem to be installing the jpg file now, even though it is marked as "force install".
Am I using this feature incorrectly? Is there a better way to have VP install the files I need it to install? I admit, I haven't read through the entire VP manual, so I may just need a simple answer.
AdrianS, you mentioned something about having another tab for all the files you need "forced" installed, how would I do that? Which file would then be my key file?
Thanks!

[Steven Carr]

NickT,

VP will try and make the installation like the one in your target tab (the latest revision).

So for example when you added the jpg in there, it installed it.

But it you don't have the jpg in the latest tab (and just one of the preceeding ones) it will not install that file.

The way i use VP is to have a complete setup of files in seperate folders for each revision. The i have my key file listed and then i have a Folder reference pointing to the folder for that revision.

As i have folder containing the revision named correctly for example:

D:\Revision\20060518\

The i have the VP Tab named as "20060518"

The "Source" directory for the folder reference is D:\Revision\#VERSIONTABNAME#\

And the key file is
D:\Revision\#VERSIONTABNAME#\app.exe

Now when i create a new version i create a new folder will ALL the files for that revision, then duplicate the last tab and rename it to the revision name. Then build...

all done.

The VP process then is a no brainer.

If any files are added to the revision, it is automatically included because of the folder reference.

*Note: i have True Update so i have a "Files that do not match" and Update.* as the actual folder refence as they TrueUpdate files are handles automatically in the update process before the VP patch takes place so they can likely be a different version than expected as well as causing "in-use" type issues. I have also customised by detect new version script in VP so that it displays a message when an old patch is run on a newer version which i can tell because of the date based numbering scheme.

[NickT]

Steve, thanks for the reply :yes - that makes a lot of sense.

However, not everything for my app is placed in the same destination folder. Some files go into "My Documents", others go in the "Local Settings" folder, etc. Would you suggest that I separate the files by the folders they must go into and ad these folders as references as well?