0

I have a project with lot of plugins and config files for them. Now I am doing a Visual Studio Setup Project for it.
I don't want to add each config file manually to the setup project, so I thought to do this:

  • create an empty zip file, say config.zip, and add it to the setup project
  • Add a pre-build action to zip all the config files into config.zip
  • Add a custom action that runs a vbs script that unzip config.zip to the right folder and deletes it.

The vbs script is the following:

sArchiveName = "Config.zip"
sLocation = "C:\Data\Configurations"

Set oFSO = CreateObject("Scripting.FileSystemObject")
Set oShell = CreateObject("Wscript.Shell")

oShell.Run """" & s7zLocation & "7z.exe"" x " & sLocation & "\" & sArchiveName & " -aoa -o" & sLocation, 1, True

'--- If I uncomment the following 2 lines, 
'--- as I click on the shortcuts the installation rollbacks.
'--- If I leave them the shortcuts work fine. 
'Set f = oFSO.GetFile(sLocation & "\" & sArchiveName)
'f.Delete True

My problem is that the shortcuts that I add in the programs menu causes the rollback of the installation. The reason is the deletion of config.zip at the end of the installation process. If I leave it everything works fine.

I have googled for a solution but cannot find anything, can someone help me?

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
Simone Cifani
  • 784
  • 4
  • 14

2 Answers2

1

This seems to be a self-repair problem.

  • Self-repair is a core Windows Installer feature which checks that your software is correctly installed whenever you launch it via an "advertised shortcut" (essentially a special type of shortcut that points to a Windows Installer feature and not directly to a file - see more information in the link provided).
  • Windows Installer tracks your zip file and discovers that it is missing, and hence correctly triggers a repair of your installation.
  • There is no good fix for this, because your deployment design is not sound. MSI is specifically designed to behave this way, and you can not disable this "self-repair" feature. Once you install the zip file it is tracked.
  • If you really want to understand self-repair there is a long answer here, but it is generally too detailed to understand without some prior idea of what it is and how it works. Still adding the link for reference: How can I determine what causes repeated Windows Installer self-repair?
  • The easiest way to deal with this is to install the config files properly via your MSI file, and remove the whole zip file. Will these config files be updated after installation, or will they be treated as read-only?
  • Visual Studio Setup Projects are very basic. The recommended way to create MSI files these days is by using the WiX toolkit. This is a new framework for creating MSI files (Windows Installer files), and it allows you to author the installation as an XML file that is then compiled into an MSI binary. It is a very elegant toolkit, but there is a learning curve.
  • Perhaps check this answer for more context on WiX: Wix generate single component id for entire tree. If you download and install the WiX toolkit and the Visual Studio plugin you will get new project types that allow the creation of a WiX XML package file.
  • Here is an answer on the "origin of WiX": Windows Installer and the creation of WiX. In essence the rationale behind its creation.
Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • It is a self-repair problem, I had understood that. But I thought there was a way to tell Windows Installer not to track a specific file. The project has a lot of plugins developed by different people, so I wanted to avoid that everyone had to put his hands into the setup project. Now I am aware that it is not possible, thanks! – Simone Cifani Aug 31 '17 at 08:20
  • 1
    There is a way, but I fear it will lead you astray. If you set a `blank component GUID` the file will be installed but never tracked or uninstalled - this would eliminate self-repair. Seems like a solution to your problem, but it is not ideal. You sometimes get problems with file overwrite on new install (new file is not installed). If you delete the zip file this problem should not occur either, but I don't like this design - it is bad deployment. The preferred option would be to use WiX and have each developer add a simple XML element to add their file once the project is set up. – Stein Åsmul Aug 31 '17 at 11:21
0

Those symptoms almost certainly mean that your custom action is failing, so the install will roll back. You'd need to post your VBScript for us to have a look.

A verbose log should show the place that the script is failing. Do an msiexec /I [path to msi file] /l*vx [path to a log file]

A common problem in VBScript custom actions is to use the WScript object, such as WScript.CreateObject. This will fail because the WScript object is provided when running in the WSH environment, but that's not happening during a call from Windows Installer.

In the script you posted, s7zLocation seems to be uninitialized.

Also, note that the code is being called from msixec.exe, running with the system account, and does not have any of the infrastructure that would see if you were running from an interactive user explorer environment (such as working directory). You need to specify the full path to all executables and files being used.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • Thanks for your answer, the vbs script does its work, anyway I updated my question with it to clarify my problem. Take a look to the comments at the end of the script. – Simone Cifani Aug 28 '17 at 06:47
  • I'll just point out again that s7zLocation is not initialized in your script. – PhilDW Aug 31 '17 at 18:20
  • I agree, but perhaps `7z.exe` is in the path or maybe even installed to the same folder as the VBScript so that the empty string in `s7zLocation` doesn't matter? @simone-cifani: If it is just in the path it will never work on target systems I would presume (unless the 7z.exe installer updates the system path and is on every target system). I find unzipping a big deployment anti-pattern btw. – Stein Åsmul Sep 01 '17 at 11:00
  • You're assuming that being called from msiexec.exe is the same as double clicking the VBScript from an Explorer window as the interactive user. See my added comment. – PhilDW Sep 01 '17 at 18:22
  • I was just theorizing since the OP claimed the script ran OK. What if he is running in immediate mode from the GUI (must be the finish dialog) or after InstallFinalize in InstallExecuteSequence? In that case he should have a user context. Somehow it is working, but I am sure it isn't in a reliable way. – Stein Åsmul Sep 02 '17 at 00:00
  • Sorry, my remark was directed at the OP, I should been more specific. – PhilDW Sep 02 '17 at 01:40
  • No problem. I really wish he would chose a different deployment strategy though. I bet he is running immediate and from the GUI. – Stein Åsmul Sep 02 '17 at 15:19
  • I am choosing another strategy. For what concern `s7zLocation` it is not initialized because I posted an extract of the script and it is a cut-paste error. In the real script it is correctly defined. – Simone Cifani Sep 04 '17 at 07:31