0

I'd like to be able to replace a file that is packaged in our msi with an external one that the user provides (It overrides some settings that are specific to the company installing the software) as well as copy over a folder of files (May or may not exist, the contents change frequently) into the destination folder.

My current approach was to have the folder and file together with the msi in a folder or on a CD and use a custom action to look for the folder and file in the same folder as the msi. This works OK as long as the installer is run from the local computer. When the installer is run from a networked location the custom action cannot get to the folder that the msi is in due to restricted permissions.

Is there a way to get around the permissions issue, or is there a better way of getting those files to their proper place?

Septih
  • 1,436
  • 17
  • 40
  • If you just want to make some files of your installer exchangeable you could set "PackageAs = vsdpaLoose". These files are then expected in the same folder as you msi. You could also set "Vital = false" if they are not required. Inside your setup project they are treated as they were part of the msi. – nik Mar 05 '12 at 17:00
  • @milter It's a good idea but the Vital=False doesn't quite work since the installer still fails if it can't find the file. It seems the property is only concerned when the msi has tried to install the file and it fails or not. – Septih Mar 07 '12 at 10:08
  • Yes, you are right, sorry. Quite i time ago i fiddled with that. Installer will still fail, but offers option to ignore and continue. So it will finish installation successfully, but it doesnt look nice for the user. Still, you could use a container file, which could be empty or not (eg zip). – nik Mar 07 '12 at 14:34

2 Answers2

0

To work in all scenarios with custom actions, you need two actions. The first runs with impersonation (non-system context), and copies from the source location to something such as the TempFolder. The second runs without impersonation (system context), and copies from TempFolder to the intended target location.

You can also explore a technique that's been called semi-custom actions, where you populate the DuplicateFile or MoveFile table with information at run-time. Ideally this will let you leverage the built-in capabilities and will still get the desired access, but I've not verified the behavior myself.

Michael Urman
  • 15,737
  • 2
  • 28
  • 44
  • By default a custom action should be run with impersonation, right? I know we had a script to set the noimpersonate bit for this action before, but even with that removed the action couldn't access the source directory. I'll have a look at the semi-custom actions but they look like they'd be easier when working with wix rather than the visual studio tool. – Septih Mar 05 '12 at 14:04
0

My solution to this was to store the location of the msi in a file in the install directory during the custom action and then have the actual program use that location to find the external files and copy them across (as the program has access to them). It's not elegant but it seems to work for customers that have tried it.

Septih
  • 1,436
  • 17
  • 40