Dynamic file links and upgrades, Work around?

[raven4281]

I have a problem trying to use upgrades with dynamic links. I've searched and browsed several boards and have yet to find a solution/work around that works for me. The heart of the problem is that using dynamically linked files and trying to do an upgrade does not copy modified files even if they have a newer time-stamp.

I realize for dynamically linked files you have to follow this link here: Dynamic Upgrades


My situation:
-Basic MSI project
-Lots of features, sub-features, and components
-Lots of dynamically linked files
-We have an existing install with several (hundred) versions already in customers hands.
-We have a ton of files dynamically linked in a lot of different sub-folders
-The folders and files that are dynamically link change every single build we do. Because of this
1) It would be a maintenance nightmare to convert to statically linked files
2) Adding a key file per directory would be a maintenance nightmare since the directories change every day
3) We can't make each dynamically linked sub-directory into a single component since the directory structure changes frequently

Our current work around is to do an uninstall and then re-install, but this takes a long time, with the amount of files we have to copy and the amount of pre-requisites that get uninstalled and then reinstalled.

It is desirable for our users to get an upgrade and only install what has change from the version on their machine, to the version they are upgrading to.


Is there another solution or feasible work around to upgrading dynamic files?

Thanks

[pkass02]

Hi,

we have the same problem. We have about 21000 file in our setup, but only 3
files statically linked (because we have to create shortcuts).

The difference to your case is, that our directory- and file structure do not
dramatically change between minor or major upgrades.

Besides some Hotfixes, which we deliver as quickpatches, we release 1 or 2
service packs as full setups. The full setup is meant for new customers.
The original plan was to make a big .MSP file for this service pack on the one
hand (for the existing customers) and a full setup for the new customers.
Even if existing customers run the full setup it should only perform an update of the changed files of the service pack.

These are the problems I experienced:

- Trial 1 - create a new setup (for the service pack) as minor upgrade
and generate .MSP from the difference between the to setups (Patch Design view):
There were that many errors on generation, that I even did not try to start searching the causes and neither fixing it.

I was astonished, that a minor upgrade setup was possible at all, as I found
out, that not only file keys for the files are created, but for each
directory there is a new component created and thus we have also
new directory keys and component keys on every setup generation.

Obviously the minor setup removes all old components and adds the new ones.
Thus is it clear, that there is no more association between the files of
the old and new setup, even if the directory and file name did not change.

This is not plausible at all. 😞

- Trial 2 - create the service pack as .MSP and deliver the full version as
original full version + .MSP which should be automatically installed
during setup of the full version.

Starting with MSI installer 2 you can add a patch on the commandline,
since installer 3 even several patches like
" ... PATCH=MYPATCH1.msp;MYPATCH2.msp ..."
and these patches should be automatically installed after the installation
of the .msi setup.

I tried it, but it did not work. The property PATCH is used to identify, if
the logics are executed in a patch context or not. But if PATCH is set
on the commandline, this property is set as well in the base setup.
I still did not find out how to determine if my logic is called during a
.MSI or .MSP setup.

Thus we ended up to deliver our service packs as full major upgrade versions,
which uninstalls the previous version completely.
The user has to enter the taregt directory again (if it was not the default),
and has even again to select the features which were installed before
(because feature migration does not work either (see http://community.macrovision.com/showthread.php?t=179043 ))
So, we have a solution, but nobody is happy with it.

This week a new requirement came up: we need to add a new feature for
the existing (full) setup. Without dynamic file linking you just add the
features and the new files (which is possible with minor upgrades) and generate
the setup again - almost identically, just with some additional features,
components and files. With dynamic file linking this is not possible.

I really wonder, why InstallShield is not able to create the same keys for the
same directories and file names on each run. The algorithms to solve this
problem are not really sophisticated. 😞

And the whole grotesque thing is, that we purchases InstallShield (11.5)
especially for this feature of dynamic file linking (and moved away from
the (free) MS Visual Studio solutions) !

😞 Peter

[pkass02]

I forgot to mention: I am using IS 11.5 but playing around with the trial version of IS 2008 ...

[raven4281]

I have achieved a partial solution to a related problem. We have a certain set of files that we are going to support patches for. By using the patch to point to the previous(base) MSI file when generating the patch, I can successfully overwrite dynamic file links with sub-folders and without key files.

When building the patch, I get an error saying file in component _GUID_HERE_ will not be updated because the key file hasn't changed. Despite this error, the patch builds and updates the file(s) fine.

[Christopher_Pai]

Have you tried IS2009? One of it's feature bullets is improved dynamic linking. However, even if it is improved, I really don't care for dynamic linking. The problem is if a file is ommitted from the upstream build then there is no way of catching that as a build failure. Although I do understand the pain in dealing with large numbers of files.

[anil1974]

Hi,

I am facing a similar problem too.
We had created a project using dynamic file linking and have released the same to customers.

I had to create a patch that will add some new file to the existing installation (no files to be replaced, just some folders and files to be added to an existing component).

On creation of the patch, IS adds each and every file into the patch rather than just the 'delta' between the latest and previous builds. The Patch creation log has following line for each file "Patch API could not create a small patch; using whole upgraded file."

In the end, I am left with a patch which exceeds even the base installer in size as all the files get included in the patch.

One thing that i notice is that the components which had only 1 file don't get inlcuded, but components who have multiple files/folders/subfolders get included in the patch

Any help would be appreciated.

[jmcallister]

I dont believe that you can use MSI's upgrade and patching scheme while using dynamic file linking. Dynamiic file linking is bad. I wrote up a post on reasons why its just awful:

http://www.adventuresintechnology.net/?p=34

[RobertDickau]

One thing to try esp. for minor upgrades and patches that use dynamic file linking is to set the Previous Package setting in the last panel of the Release Wizard, which tries to ensure the File, Component, and Media keys match up between the before-and-after packages.

[anil1974]

Thanks Robert,

Your suggestion worked. I could create a patch which now includes just the 'delta' data and is much smaller (as expected).

I am facing a different problem though now.

I run the base installation and then install the patch which adds some new files to the existing feature, i have kept all the files in a new component.

The patch installation goes fine, now when i go to add remove programs and try to select / deslect some features, it throws error 1334 which goes "Error 1334. The file 'xxx.xxx' cannot be installed because the file cannot be found in the cabinet file 'Data1.cab'. This could indicate a network error reading the cdrom, or a problem with this package."

This happens for many files and different users are reporting different file names. Any ideas?