Patch creation problem with AdvInst 3.9

[AlexH]

Hello,

I'm having great trouble creating a patch MSP using AdvInst. In fact, I never managed to create a working MSP in any AdvInst version, but right now I'm using 3.9. Building standard MSI packages work fine.

The original project MSI was created with AdvInst 3.5. Since then, a few files were changed, nothing out of the ordinary. I follow the exact instructions as given in the patch tutorial: I load the original AIP file into AdvInst 3.9, I modify the version, and select NO when asked to create a new product code. I rebuild the MSI. Installed on its own, this new MSI works flawlessly.

I then create an MSP from both MSIs. I install the original MSI on a virgin Windows XP install. I launch the patch MSP, which runs without errors. But none of the original project files were updated or modified in any way.

After applying the malfunctioning patch, the Add/remove programs won't uninstall the software anymore. It pretends everything went fine (and the software entry is removed from the installed software list), but all files and resources such as shortcuts are left untouched.

Any advice ? This is an important patch, and our customer is expecting it for next week...

Thanks !

EDIT:
OK, now I'm getting a little nervous. I thought that if patch creation failed, I always had the alternative to create a completely new MSI, using a new product code, but the same upgrade code. That way, the product would be updated aswell, just the MSI would be a larger than an MSP.

Well, it doesn't work.

I take the original AIP file, as above for patch creation. This time, I let AdvInst assign a new product code after modifying the version. Essentially following the simple example from the tutorial. The MSI builds without errors.

After running the MSI, the application data is updated, but the main executable (which should also be updated to a new version), has disappeared entirely, including desktop shortcuts to it !

This is not good. I need a solution to these problems ASAP.

- Alexander

[gigi]

Hi,

In order to determine the cause of this problem, please send the AIP files for both packages and for the patch to support at advancedinstaller dot com. Also if you can please provide us a link from where to download both generated msi packages.

Regards,
Gigi
_________________
Gheorghe Rada
Advanced Installer Team
http://www.advancedinstaller.com

[AlexH]

OK, I'll send you the AIP files ASAP.

For the MSIs, it won't be possible since they contain confidential information. If you really need them, I can still try to reproduce the problem with other non-critical files.

Thanks,
Alex[/list]

[Ionut]

Hi Alexander,

A. Regarding the patching problem: your package uses the "File Associations" dialog. As a result, a Component named "ExtReg" is added dynamically to the MSI database during the build process. Therefore, when creating the patch, the Component rules are broken: there is an "ExtReg" Component with different GUIDs for the "Target" and "Upgraded" images.

This is a bug in AI and it will be fixed in the next version which will be released soon.

In the meantime, you will find below a script that sets the GUID of the "ExtReg" Component for a MSI file to the GUID of this Component from another MSI file. This change can also be performed manually using Orca.

Code: Select all

'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
' extregmod.vbs
' Usage: cscript extregmod.vbs <sourcefile.msi> <destfile.msi>
'
' Script that sets the `ComponentId` column of the ExtReg Component of <destfile.msi>
' to the value of the same column from <sourcefile.msi>
'
' That is, after this script is run, the ExtReg Component of <destfile.msi> will have
' the same GUID as the ExtReg Component of <sourcefile.msi>
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Option Explicit

Const msiOpenDatabaseModeReadOnly = 0
Const msiOpenDatabaseModeDirect = 2

' Show help if no arguments or if argument contains ?
Dim argCount : argCount = Wscript.Arguments.Count
If argCount > 0 Then
  If InStr(1, Wscript.Arguments(0), "?", vbTextCompare) > 0 Then
    argCount = 0
  End If
End If

If argCount < 2 Then
    WScript.Echo "Usage: cscript extregmod.vbs <sourcefile.msi> <destfile.msi> " &_
      vbLf & "This script sets the GUID of the ExtReg Component of < destfile.msi> " &_
      vbLf & "to the GUID of this Component from <sourcefile.msi>" & vbLf &_
      vbLf & " The 1st argument is the path to the  source MSI file" &_
      vbLf & " The 2nd argument is the path to the MSI file that will be modified"
  WScript.Quit 1
End If

' Get the paths of the 2 database files
Dim sourceMsiPath : sourceMsiPath = Wscript.Arguments (0)
Dim destMsiPath : destMsiPath = Wscript.Arguments(1)

Wscript.Echo "Database paths: " &_
  vbLf & "  Source MSI: " & sourceMsiPath &_
  vbLf & "  Destination MSI: " & destMsiPath & vbLf

' Connect to Windows installer object
On Error Resume Next
Dim installer
Set installer = CreateObject("WindowsInstaller.Installer") : CheckError

WScript.Echo "Connected to Windows Installer object"

Dim database

' Open the source database
Set database = installer.OpenDatabase(sourceMsiPath, _
               msiOpenDatabaseModeReadOnly) : CheckError
WScript.Echo "Opened source database"

Dim thecommand,view,record

' Extract the GUID of the "ExtReg" Component
thecommand = "SELECT `Component`.`ComponentId` FROM `Component` " &_
             "WHERE `Component`.`Component`='ExtReg'"
Set view = database.OpenView(thecommand) : CheckError
view.Execute : CheckError
Set record = view.Fetch : CheckError
Dim extregGuid : extregGuid = record.StringData(1)
Wscript.Echo "  The GUID of the ExtReg Component is " & extregGuid

Set database = Nothing
Set view = Nothing
Set record = Nothing

' Open the destination database
Set database = installer.OpenDatabase(destMsiPath, _
               msiOpenDatabaseModeDirect) : CheckError
WScript.Echo "Opened destination database"

thecommand = "UPDATE `Component` SET `Component`.`ComponentId`='" &_
              extregGuid & "' WHERE `Component`.`Component`='ExtReg'"
Set view = database.OpenView(thecommand) : CheckError
view.Execute : CheckError
database.Commit : CheckError
WScript.Echo "  The GUID of the ExtReg Component has been set successfully"

Set database = Nothing
Set view = Nothing
Set record = Nothing
Set installer = Nothing
Wscript.Echo vbLf  & "Done"


Sub CheckError
   Dim message, errRec
   If Err = 0 Then Exit Sub
   message = Err.Source & " " & Hex(Err) & ": " & Err.Description & vbcrlf & query
   If Not installer Is Nothing Then
      Set errRec = installer.LastErrorRecord
      If Not errRec Is Nothing Then message = message & vbLf & errRec.FormatText
   End If
   Fail message
End Sub


Sub Fail(message)
   Wscript.Echo message
   Wscript.Quit 2
End Sub

A BAT file that will invoke the script might be useful:

Code: Select all

@echo off
cscript extregmod.vbs original_package.msi upgraded_package.msi

In order to use this script:

1. After building the Target and Upgraded MSI packages, execute the script specifying their paths. This will ensure that the "ExtReg" Component will have the same GUID for both MSI packages. Use a BAT file as specified above.

2. For a minor upgrade patch (that is, the "ProductCode" remains the same, the "ProductVersion" changes), the name of the Upgraded MSI file must be the same as the name of the Target MSI file. Thus, after performing the GUID change operation as specified above, store the 2 MSI packages in different folders and with the same name).

3. Now change the Patch project accordingly and build the MSP between the target and upgraded MSI packages (they will have the same name and the same Component GUIDs).

4. Test the patch on a clean system.


B. Regarding the upgrade problem using a new MSI package: this is a really strange issue and I am not sure what is causing it.

1. Does this happen on the machine on which you have tried previously to apply the patch or on a fresh Windows installation? Because the patch failure may have caused inconsistencies in the Windows Installer configuration information.

2. If this happens on a clean machine, what version of Windows Installer is available on this computer? Determine the version of "msi.dll" from "Windows\system32". Does this problem appear on other computers as well?

3. Create a verbose log when installing each MSI package (the original and then the upgrade MSI). Use the following command to do this:

Code: Select all

msiexec /I package.msi /L*V "C:\package.log"

Send both log files to our support email address so I can investigate this issue further.

I hope this helps.

Regards,
Ionut

[AlexH]

Thank you for your reply, this has been very helpful. I'm going to try the script right away.

About issue B, it did in fact happen after I installed the failed patch. I didn't try it on a second machine. So the reason could very well be a corrupt Windows Installer database. I'm going to test it on a fresh Windows install tomorrow, and report back.

Best regards,
Alexander

[AlexH]

Unfortunately, the patch script doesn't work 100%. After installing the MSP generated from the GUID-corrected MSI, all files are correctly updated, except for the main executable, which stays unmodified.

I have also reproduced the scenario B error on two different machines, both with fresh Windows installs. The problem is exactly the same as before: all files are updated, but the main executable is removed from the final install, instead of being updated.

Interestingly, it's both this main executable that is either not updated, or deleted in both scenarios A and B. And it's also this executable that uses the ExtReg component. Coincidence ?

Anyway, the msi.dll version is 3.0.3790.2180 (essentially, a clean install of XP Professional from its CD, without any service packs and/or Windows update applied).

I'll send you the two MSI log files by email.

Regards,
Alexander

[gigi]

Hi,

all files are updated, but the main executable is removed from the final install, instead of being updated.

This problem may be because of a bug in Windows Installer that causes same times to not update a file if both versions (old and new) of it are the same. To avoid this you can modify the version of your main executable (for ex: from 1.3 to 1.3.1).

If this not solves the problem then please sent us the log created when installing each MSI package:

Code: Select all

msiexec /I package.msi /L*V "C:\package.log"

Regards,
Gigi
_______________
Gheorghe Rada
Advanced Installer Team
http://www.advancedinstaller.com

[AlexH]

The file versions are different.

I was able to reproduce the problem on a highly simplified MSI, that will only contain the main executable. I will send you an archive with both MSIs and AIPs, the original (1.3.1) and the new one (1.3.2).

When the 131 MSI is installed, the executable is correctly placed into its folder, a desktop shortcut is created, a file association is set, and a few other things. When installing the 132 version as an update on top of it, the file dissappears instead of being updated. Installed on its own (ie. not as an update over 131), the 132 version will work.

(PS: trying to run the installed executable will obviously fail due to missing DLLs)

Best Regards,
Alexander

[AlexH]

OK, works perfectly now. Thanks !

Regards,
Alexander