Web update issues

[timbojones]

I'm testing the web deployment functionality of SB5, and I find a number of issues:

1) If I delete a file from my installation package, it is not deleted from a user's machine when they upgrade. It is left orphaned and will remain on their system until deleted manually -- uninstallation does not remove it either.

2) Web installation claims that it will only download files that have changed between versions, but it downloads all the files regardless.

3) The FTP uploader uploads all files regardless of whether they have changed. In addition, if I have deleted any files, I am left with extra installer files that are not actually in use.

My goal is to provide an installer that will both a) install on a clean system and b) update an existing installation by downloading only files that have changed. If files are deleted from my build, they should be deleted when users upgrade. Can SetupBuilder meet my needs?

[linder]

Hi Tim,

Thank you for your message and your interest in SetupBuilder.

> I'm testing the web deployment functionality of SB5, and I find a number
> of issues:
>
> 1) If I delete a file from my installation package, it is not deleted
> from a user's machine when they upgrade. It is left orphaned and will
> remain on their system until deleted manually -- uninstallation does not
> remove it either.

You only have to add a "Delete File" script item and you are done.

> 2) Web installation claims that it will only download files that have
> changed between versions, but it downloads all the files regardless.

Did you enable the "Check File (CRC)" File Replacement Option (see File
Properties dialog)?

> 3) The FTP uploader uploads all files regardless of whether they have
> changed. In addition, if I have deleted any files, I am left with extra
> installer files that are not actually in use.

Yes, this is correct and by design. It's not possible to automatically
upload only "new files". The date/file stamp of files on the server is
always <> the original file/time stamp. And to generate a CRC32 of all
server files, we would have to download all files first (not a good
idea).

> My goal is to provide an installer that will both a) install on a clean
> system and b) update an existing installation by downloading only files
> that have changed. If files are deleted from my build, they should be
> deleted when users upgrade. Can SetupBuilder meet my needs?

No problem. Most of our customers are doing this all the time. And our
own SetupBuilder 5 full installs and web installs are doing this. The
web install only downloads changed files are deletes files not needed
any longer.

Please drop me a line if you have any further questions.

Friedrich

[timbojones]

You only have to add a "Delete File" script item and you are done.
Is there a way to automate this? Our product contains over 7000 files, included with a *.* filter. Diffing directories between builds and manually adding Delete File items for each deleted file is more work than I want to do.

I'll have to keep a list of Delete File items for every file that's been deleted ever, so that a user upgrading from version 1 to version 3 doesn't miss the files that got deleted in version 2. I have to wrap each Delete File in an If File/Folder exists block to prevent errors when another user upgrades from version 2 to version 3. If a file is added back, I need to remove its Delete File item. I need to consider duplicate items as I add new entries.

My experience with Wise suggests that Windows Installer keeps track of installed files via 'components'. Seems like it should be possible to figure out which files/components no longer exist and delete them.

SetupBuilder is everything we're looking for, except for this issue.

[linder]

Tim,

I this an "update only" installation, or does it also install the full version?

If it is an update, I can think of a new switch in the Auto Update Generator to let SetupBuilder automatically add remove files/folder statements in one of the next builds. It should not be a problem to add this.

What do you think?

Friedrich

[timbojones]

Ideally, we would have one set of release files with one installer. Our current solution involves one monolithic installer which we update with each released version and a series of patches between each release. The patches are nice and small, but very fragile.

If we were to release a full install and an update install, we'd have to disallow updates via the full installer.

[linder]

Okay, thanks for the info.

IMO, it's always a good idea to provide both full installs and (web) updates because it's easier to maintain.

If something goes wrong with the update, the user can still perform a full install.

[timbojones]

IMO, it's always a good idea to provide both full installs and (web) updates because it's easier to maintain.

It is possible to do that without maintaining two nearly-identical parallel installer projects?

[linder]

What we do is the following:

We create a full SetupBuilder installation. This can be used by new users and those "update users" who are interested in a clean install.

Then we let "Auto Update Generator" create an (web) update for us. This update makes it possible to bring all (5.0, 5.1, 5.2, etc.) SetupBuilder 5 versions to the latest build.

I have a few ideas for future SB5 versions on how to handle updates. If you would like to see specific (updates) features in SetupBuilder 5 just drop me a line. SB5 works rock solid now. We are working on enhancements now...

Thanks,

[timbojones]

How would I enable Web Update in the full install to refer to the update installer?

Our compressed installation is 1.5 GB, I don't want our users to have to download that all at once. That's why we're looking at web deployment in the first place. Seems like you're suggesting a single monolithic installer and a partial update installer?

Do I understand correctly, that you run auto update using the first vs. the latest revision? Were file deletion implemented as part of auto-update, that method would still leave orphans if they are added after v1 and deleted later.

I think in order for file deletion to work properly in an automated fashion, the installer will have to know which files are part of the existing installation, and remove them if they are not part of the incoming upgrade.

[linder]

Tim,

You only have to configure the iDeploy Web Update client (see "Using Web Update in Your Installation" online help or PDF manual topic). This gives your software the ability to check a specified location on the Internet for updates.

Yes, we run Auto Update using the first (in our case the Gold version) vs. the latest revision.

Thanks,

[timbojones]

How would I enable Web Update in the full install to refer to the update installer?

My confusion here came because we really want the full installer to be a web install as well. 1.5GB of compressed data does not translate well to a single-file download.

The answer I was looking for is: Both the full installer and the update must have the same [EXENAME]. They should both refer to the same update location. But they should be accessed using two different URLs.

I think that for now we'll do the simplest thing, maintaining a single installation project and adding Delete File commands manually as necessary.

If you add file deletion to AutoUpdate, we will consider the 2-project method. I'm still concerned about the case where version 2 adds some files and version 3 deletes them. If a user with version 2 applies the AutoUpdate that was generated using version 1 and 3, those files will be orphaned. This is of course better than the situation now where all deleted files get orphaned.

Ideally, file deletion would be taken care of automatically using a single installation project. Does SetupBuilder not store a list of installed files?

[timbojones]

What is the best place in the install sequence to put the Delete File commands? My best guess is in the Install Files section, before the Install File commands. Seems like this ordering implies a side effect: any mistakenly deleted files will be replaced. Is that true?


I'm still concerned about the case where version 2 adds some files and version 3 deletes them. If a user with version 2 applies the AutoUpdate that was generated using version 1 and 3, those files will be orphaned.

Ideally, file deletion would be taken care of automatically using a single installation project. Does SetupBuilder not store a list of installed files?

There has not yet been any discussion of this issue; I am eager to hear your thoughts.

[linder]

What is the best place in the install sequence to put the Delete File commands? My best guess is in the Install Files section, before the Install File commands. Seems like this ordering implies a side effect: any mistakenly deleted files will be replaced. Is that true?

Tim,

You can place it wherever you want, but I would suggest to place it in the Modify System section.

[linder]

If you add file deletion to AutoUpdate, we will consider the 2-project method. I'm still concerned about the case where version 2 adds some files and version 3 deletes them. If a user with version 2 applies the AutoUpdate that was generated using version 1 and 3, those files will be orphaned. This is of course better than the situation now where all deleted files get orphaned.

Ideally, file deletion would be taken care of automatically using a single installation project. Does SetupBuilder not store a list of installed files?

I checked with the other installation systems and I think they also do not have a solution available to this update scenario.

What do you think would be the best solution? We are always looking for good ideas to improve the SetupBuilder 5 product.

Thank you for your time.

[timbojones]

What do you think would be the best solution? We are always looking for good ideas to improve the SetupBuilder 5 product.

It seems to me that the only way to accomplish this is to create a list of files when the product is installed. When the user runs an upgrade, compare this list to the list of files in the upgrade, and delete any that are missing in the upgrade. This method ensures that no files are orphaned, but will not remove anything generated by the program during runtime (e.g. documents, saved games, configuration files). I believe Wise has this capability -- if you select the right options, it will assign a GUID to each file and store these in the registry.

I want to thank you also for your time. Your quick response to my questions was a major factor influencing our decision to purchase a SetupBuilder license. I evaluated 6 installer builders and SetupBuilder came out on top owing to ease of use, flexibility, features, and your involvement on these forums. And speed -- compiling our product in SetupBuilder takes 20 minutes where Wise took hours.

[LSConsulting]

Welcome to the club ;) We evaluated 8 installation systems, but SetupBuilder beats them all. (Macrovision) InstallShield 11.5 or (Altiris) Wise - nightmare products of the year. Don't want to mention the other tools here. They don't come close to what SetupBuilder can do.

Andrew McKay

[linder]

Tim,

Thanks so much for your kind words.

We'll brainstorm on how to improve this update scenario.

[timbojones]

Right now I wish I could import a script from a plain text file. I have a plain text list of files to delete. It would be a simple matter to write a script to convert that list into a list of SetupBuilder script commands. Copy & pasting each of hundreds of file names into the script editor is a huge pain!

[timbojones]

Our current update included the deletion of over 1400 files (mostly unused textures that we purged from source control). I decided that manually entering delete file or delete folder blocks for all of them is too much work and came up with a workaround.

I get a list of files from a directory diff, saving the list to a text file "delete.txt". Each file is listed as e.g. ".\data\textures\faketexture.bmp". The diff tool lists files with the diff root as '.' automatically. On subsequent updates I will append the new list at the end of this file, so users upgrading from v.1 to v.3 don't miss the files deleted in v.2.

I created a batch file containing:

@echo off

for /f "delims=" %%i in (delete.txt) do (
del "%%~fi" 2>nul
rd "%%~dpi" 2>nul)

This batch file iterates through the files listed in delete.txt, deleting each and attempting to remove the subdirectory if the deletion emptied it.

"delims=" replaces the default delimiter set (space and tab) with an empty set. This ensures that each line is treated as a single whole entry. Without this, the batch can't delete a file containing a space.

"%%~fi" expands each entry to a fully qualified path, enclosed in quotes. "%%~dpi" expands each entry to a drive letter and path with no file name, enclosed in quotes. The quotes are important in case the user has installed to a path with spaces in, which is likely.

2>nul throws away all error output, so the user doesn't see "Could not find foo" for files that don't exist or "The directory is not empty" if the file was not the last in the directory.

In my SetupBuilder script, I added

Install File "C:\Installer\delete.bat" to %_SB_INSTALLDIR%\delete.bat
Install File "C:\Installer\delete.txt" to %_SB_INSTALLDIR%\delete.txt
Run Program %_SB_INSTALLDIR%\delete.bat (Always Install) (Wait)
Delete Local Files "%_SB_INSTALLDIR%\delete.bat"
Delete Local Files "%_SB_INSTALLDIR%\delete.txt"

The Run Program entry has 'Hide Window' checked, and 'Default Directory' set to "%_SB_INSTALLDIR%". The default directory ensures that when delete.bat runs, its current directory corresponds to the root of the files in delete.txt

I placed these lines in the [ Install Files ] section, before the Install File *.* line. In this way, if a file gets deleted and later re-added, it will end up being downloaded again, but is ensured to end up in the final installation.