cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
BizerbaDev
Level 6

Minor update with Basic MSI: New files are not copied to target?

Hi!

I have quite a lot of experience with InstallScript setups but my company has decided to use Basic MSI install setups for new products. I have created a new basci MSI setup project for a new product of my company that is currently still in development. This setup project is built every night with the current sources by one of our build machines so we can provide current test versions to managers and sales people in order to discuss the current progress. With each new build the minor version number is increased which results in a minor upgrade when the setup is executed on a machine that already has an old version of the product installed.

While the so created install setups work fine for new installations we noticed that new files that where added to the product will not be added to the target machine's installation when an update is made. These new files that I'm talking about are part of a component that uses dynamic file linking.

So these are the facts:
- All files are copied when the setup makes a new installation.
- If an update is made to an existing installation then new files are missing while old files seem to be updated correctly.
- In the log file of the update installation the new files are not even mentioned.

I think this is basic functionality so there must be an easy way to fix this behavior. In my old InstallScript setups I never had a similar issue. Can someone please point me in the right direction on how to solve the problem?

Regards

Ralf
Labels (1)
0 Kudos
(5) Replies
ch_eng
Level 7

Ralf,

I am not sure this helps, but I've had the same issue that you described. I don't think there is a solution with Basic MSI projects or even InstallScript MSI projects. I had the pleasure of converting several projects from InstallScript MSI to InstallScript Only to get that functionality to work. I vaguely remember someone from support telling me that it is a Microsoft limitation (since they govern how MSIs work) - which is why there is no "Always Overwrite" option for components in InstallScript MSI projects like there is for InstallScript Only projects. I hope you have better luck!

HTH
0 Kudos
Reureu
Level 10

Hi Ralf,

We did exactly the same as you while our product was under development. We used Dynamic File Linking for resources that were likely to be quite volatile (images, texts, config files).
Using Dynamic Files is great in one way, because you don't have to worry about changes in the amount of files that are added to your installation package.
But it has a hell of a drawback: You won't notice if a file is removed.
And the point is: you are not allowed to remove a file (or rename it) in a minor upgrade scenario.

There is a workaround: in theory you could use the RemoveFile table to list the files that have been removed between 2 builds, but that's precisely the sort of things you are trying to avoid by using dynamic files.
Moreover, the component and file keys in the resulting MSI database are random for dynamic files, which makes it practically impossible to handle in the RemoveFile table.

So you can do 2 things:

  • Bare in mind that you may not remove files if you want to perform a minor upgrade.There are 3 steps that will allow you to get notified if a file has been removed:
    [LIST=1]
  • Make sure all dynamic links use the "Create best practice components" setting.
  • Under "Media->Upgrades->Prepare Setup for Upgrade Scenarios->Upgrade Windows Installer Setup", add a Minor Upgrade Item which will allow to perform validation against the previous build of your package.
  • Under "Media->Releases->Build", use the "Previous Package" setting to point on the previous build of your package. This will allow to keep the dynamic file keys consistent across releases.

  • Forget about Minor Upgrades and go for a Major Upgrade.


    I hope that helps.
  • 0 Kudos
    BizerbaDev
    Level 6

    Hello Reureu,

    I had a small discussion with a setup consultant and we discussed the whole scenario. Unfortunately the Major Upgrade really sucks because it will forget about selected features and the install path - I really wonder how anyone can suggest this here without mentioning this major drawback! Another strange thing is that the user gets a small dialog for minor updates that tell him that he's about to perform an update, but for the major update this is not the case: It just removes the old installation without any notice! Building in this functionality manually is of course beyond all accaptable effort.

    Furthermore I have to emphasize that we create setups on daily build basis on order to provide current beta setups for product management in our company. I cannot implement new update logic every day...

    I will take the following measures:
    1. I'll will always DEactivate the "Create best practice components"-option in order to only have one component created per dynamic file linking. In this case no other component keys are crated that may change between builds. I also will not need the "Previous Package" setting then.
    2. This also means that sub fulders cannot be included in the dynamic file linking. Therefore a dedicated component is needed for each subfulder. We only have subfolders for each translated language (de, en, es, fr, ...). Although it is not nice I can still handle this effort.
    3. Usually files will not be renamed or removed in our software. Those few cases that will occur will have to use the RemoveFile table. Again this is not nice, but I can live with that.

    Looing back on how this went I would choose InstallScript over BasicMSI if only the silent install of a InstallScript setup would not be so complicated (Response files needed!).

    I still wonder why Microsoft is making setups so darn complicated.... Creating install setups for a complicated product is a real pain.

    Regards

    Ralf
    0 Kudos
    Reureu
    Level 10

    Hi there,

    I agree with you: the major upgrade has a few drawbacks, but it allows you to do what the minor upgrade does not support: you can remove components/files in a new version of your product.

    You are facing the usual problem with dynamic links: you want InstallShield to automatically generate components for all files and subfolders that are present in a source folder, but you have to support minor upgrades, so you are not allowed to remove components/files.

    Because you are using dynamic links, you will not even notice when a file is removed, which in turns will provoke errors in your minor upgrade scenarios.

    If you really want to use dynamic links and stick to minor upgrades, then you need to perform validation so that you are notified of such problems (see my previous post)
    If the validation detects that some files have been removed, then you have to change your ProductCode, which brings you to the major upgrade scenario.

    As for the drawbacks of Major Upgrades:

    • The feature state: there is a standard action called MigrateFeatureStates. More about it here: http://msdn.microsoft.com/en-us/library/aa370034%28v=vs.85%29.aspx
    • As for the installation path, you can actually implement a custom action that will only run when the major upgrade takes place. This custom action can detect the installation path of the previous installation by calling MsiGetProductInfo, and call MsiSetTargetPath to set INSTALLDIR accordingly.

    By default the user experience of a major upgrade is nearly the same as a first installation (http://helpnet.flexerasoftware.com/installshield20helplib/Content/helplibrary/MajorUpgrade.htm).
    But you can customize the behaviour of your installation during a major upgrade. You can hide the feature selection dialog, you can also hide the target folder selection dialog. That's up to you.

    Last but not least, you can actually update the ProductCode with every build: If you are running a build script, you can use the IS automation. If your build is based on MSBuild, you can override the ProductCode property at each build.
    0 Kudos
    DLee65
    Level 13

    MillionsterNutz wrote:
    Hello Reureu,

    I had a small discussion with a setup consultant and we discussed the whole scenario. Unfortunately the Major Upgrade really sucks because it will forget about selected features and the install path - I really wonder how anyone can suggest this here without mentioning this major drawback! Another strange thing is that the user gets a small dialog for minor updates that tell him that he's about to perform an update, but for the major update this is not the case: It just removes the old installation without any notice! Building in this functionality manually is of course beyond all accaptable effort.

    Furthermore I have to emphasize that we create setups on daily build basis on order to provide current beta setups for product management in our company. I cannot implement new update logic every day...

    I will take the following measures:
    1. I'll will always DEactivate the "Create best practice components"-option in order to only have one component created per dynamic file linking. In this case no other component keys are crated that may change between builds. I also will not need the "Previous Package" setting then.
    2. This also means that sub fulders cannot be included in the dynamic file linking. Therefore a dedicated component is needed for each subfulder. We only have subfolders for each translated language (de, en, es, fr, ...). Although it is not nice I can still handle this effort.
    3. Usually files will not be renamed or removed in our software. Those few cases that will occur will have to use the RemoveFile table. Again this is not nice, but I can live with that.

    Looing back on how this went I would choose InstallScript over BasicMSI if only the silent install of a InstallScript setup would not be so complicated (Response files needed!).

    I still wonder why Microsoft is making setups so darn complicated.... Creating install setups for a complicated product is a real pain.

    Regards

    Ralf


    You can get the previous INSTALLDIR from a system search and the set the directory based on the system search. I include this process in all of my installations so that upgrade paths are preserved. This is especially critical in the area that I work where preserving previous data connections is critical and required by law.

    Ralf already spoke to the issue of migratefeaturestates. As long as your feature structure remains the same or similar - do not delete / rename features. You can add features.

    One of the things to consider for Dynamically linked data is to NEVER, NEVER include sub folders. If there are sub folders create a dynamic link to this. If sub folders can be added / removed dynamically then I would look to using automation to modify the install at build time.

    The second thing to consider for dynamically linked data, make sure you keep the previously released MSI package file. In your release settings (using the release wizard) you can link to the previous MSI. This should preserve the Dynamically linked items BUT only to the first level. That is why you should never include sub folders. In my previous employment I got caught with this problem.

    Who knows, by linking the previous package, you may fix your minor upgrade issues.
    0 Kudos