/build/static/layout/Breadcrumb_cap_w.png

DuplicateFile and Windows Installer asking for Source

Hi IT-Ninjas,

Using Windows Installer technology I am trying to package FileZilla which needs filezilla.xml in the user profile as this sets the language of the application. I tried to achieve this by copying the file via DuplicateFile to the user profile.

The problem is: DuplicateFile is not working when the MSI which installed the application is removed from the computer.
Instead the Windows Installer comes up asking for the source MSI when launching the advertised shortcut.

I have absolutely no clue why this is happening and don't know how to fix this. I am also confused about "msiexec /fup ..." is working - the file is duplicated just fine. But this is not how a user starts the self healing, so any thoughts on this are highly appreciated.

Here is what the important stuff looks like:
HpC7N4.png

I don't see any mistakes there.

Thanks in advance
kami

Edit:
I uploaded the corresponding MSI for those who are interested: https://www.dropbox.com/s/49aswqqu31p5xfs/FileZilla.msi?dl=0
Asked 9 years ago 1950 views
0 Comments   [ + ] Show comments

Answers (8)

Posted by: anonymous_9363 9 years ago
Red Belt
0
DuplicateFile is the wrong way to go about this. And you shouldn't remove the source MSI if you want repair/self-healing to ever work!

Abandon Active Setup: it's a one-time only affair.

You need to re-jig the feature tree so that self-healing takes place. Essentially, you create a new feature containing the user profile component(s). Remember that the component key path must be a registry entry (make one up: I typically use something like HKCU\Software\[ClientName]\[ProductName]\SelfHealing\[ComponentID). You then make the feature containing the advertised entry-point (the shortcut in this case) a child of your new feature.

Seek out John McFadyen's excellent blog about self-healing. 
Comments:
  • Isn't that what I've done there? Have a look to the screenshot: CurrentUser component belongs to feature CurrentUser and contains a HKCU-Key and the DuplicateFile action. The rest of the package is in the sub-feature "FileZilla_Feature". Why is DuplicateFile the wrong way to copy a file to the user profile? I always thought this is how it should be done. - kami 9 years ago
Posted by: anonymous_9363 9 years ago
Red Belt
0
I don't recognise what product that is so I can't easily interpret what it's telling me. Particularly confusing is the reference in the CurrentUser component to INSTALLDIR. It also clearly shows ActiveSetup being used.

It will be much easier for you if you read John's article.
Comments:
  • ActiveSetup is not used because I've created advertised shortcuts. I only use this registry key as KeyPath for the CurrentUser component. (It's kind of like the default location for this by guidelines).

    To me it just makes no sense that self-healing doesn't work while msiexec /fup works, even without the MSI being around.

    I read John's article, but it doesn't mention FileDuplicate as a solution for this. I know this must work this way (http://www.ewall.org/tech/msi/self-healing) but for me in this case it doesn't. But why? - kami 9 years ago
Posted by: anonymous_9363 9 years ago
Red Belt
0
Simply put, it doesn't mention it because it's not used.

For most packagers of any worthwhile experience, the solution to populating user profile data is by self-healing using the feature tree and advertised entry-points. 

If you wish to persist in trying to get DuplicateFile to work, good luck. I'll stick with the method I've used for what must be hundreds and hundreds of packages.
Comments:
  • If you don't use DuplicateFile and the MSI is not around for some reason (e.g. working on a laptop abroad), how can this work? :-) - kami 9 years ago
Posted by: anonymous_9363 9 years ago
Red Belt
0
Surely you're caching the package locally for laptop users for precisely that reason, no? Actually, given that storage is so cheap nowadays, why would you not cache packages, period?
Comments:
  • You do (and you are absolutely right), I would - but I can't. The fact that there is not enough space for a large numer of installation packages to be locally cached is just given. That's why I need to get this to work somehow. - kami 9 years ago
Posted by: anonymous_9363 9 years ago
Red Belt
0
I give in! :-)

Post the structure of the DuplicateFile table here.
Posted by: Badger 9 years ago
Red Belt
0

you have put the active setup keys in HKCU, Wrong.

They go into HKLM, when a user logs in if they keys are NOT in HKCU it puts them there and process's the stub path to the do the repair.

ONLY use the active setup when you don't have entry points, (COM) or advt shortcuts.

Posted by: Badger 9 years ago
Red Belt
0

what you want to do in this case... i have written this before I am sure..

is put the file into ProgFiles... duplicate it from there to the users profile.

The comp putting it into the users profile will need to have an HKCU key as a key path. When a user launches the advt shortcut, it will initiate a repair, notice the HKCU key path is not there, it will go upto the comp, add the reg key, and the files that are in the component. In this case a duplicate file safely tucked away in Progfiles.... no need for the MSI source to be used.

I do this quite a lot at sites.

Posted by: EdT 9 years ago
Red Belt
0
I'm not going to try to figure out the structure you have posted above in any detail, but it does appear wrong.  VBScab is correct that self healing is the most reliable solution. What appears to be wrong in your structure is that the User feature is not the PARENT feature of all other features in the application. The MSI integrity check is triggered by an advertised entry point, and if the feature containing the AEP is intact, the integrity check proceeds UP the feature tree (but not to the sides if there are parallel features) so if the user feature is the parent, it will get checked also. A missing HKCU registry key will therefore trigger a repair of the user feature and install the missing component(s).  However, whatever method you use for self healing does not remove the installed components so you may wish to include some code to delete that file during an uninstall - perhaps writing a delete command into the runonce registry key.
As for using the DuplicateFile table - do you understand how this works ?  Entries in the DuplicateFile table are links to components only.  Therefore, the duplicate file only gets installed when the component it is linked to gets installed. This component will have a key path in the normal course of events. During self healing, the key path of the component will be checked, and if it already exists, then no repair takes place so the duplicate file is neither checked nor installed if missing.  If you want duplicate files to be installed during self healing then you have to ensure that the main component does not get installed either. This of course means that the source of the install must be present locally.

The way I would approach this would be somewhat different if you cannot store the sources locally, as self healing will need access to the original source whatever you do in the methods discussed above.  Since the XML file is nothing more than a text file, instead of having a file install approach, just create a vbscript custom action to write this XML file line by line as this can then work from the locally cached MSI file without needing access to the source.
Of course, if you are running Windows 7, the entire application gets cached anyway as otherwise you run into code signing errors during uninstall if the original install was code signed. What Microsoft failed to do was to automatically specify this cached copy as a source for repair.  I wrote an article three years ago which provides a method of fixing this which you can adapt as appropriate:
https://www-secure.symantec.com/connect/articles/reducing-windows-installer-disk-wastage-windows-7

As for converting text files to a vbscript, I also wrote some code to do that for you. It is not bomb proof but with the output file it generates, a few edits should give you a working solution in a fraction of the time it would otherwise take:
https://www-secure.symantec.com/connect/articles/wisescript-packaging-utility-1
Comments:
  • Dear EdT, CurrentUser *is* the parent of the other feature. I uploaded the MSI, because screenshots leave questions open. If you could have a look on it, that would be much appreciated. Thank you! https://www.dropbox.com/s/49aswqqu31p5xfs/FileZilla.msi?dl=0 - kami 9 years ago
    • I'm guessing you have not enabled verbose logging in the registry and checked installation logs, or checked the event viewer. I think you are running into a problem caused by the subtlety of the operation of the DF table. Specifically:
      Component_
      An external key to the first column of the Component table. If the component identified by the key is not selected for installation or removal, then no action is taken on this DuplicateFile record.

      Since this is a repair scenario and not installation or removal, no action is being taken.

      That is why the general consensus here is to avoid using the DF table and use one of the other methods. Also, I would never recommend using the Active Setup registry keys to store registry entries that are nothing to do with Active Setup. This is just a recipe for confusion in the future especially if someone else has to update your application. - EdT 9 years ago
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ