I have created and Install with product version 1.0.0 and then a second install with product version 1.0.1 this is a minor change (fixed bug in exe) so I did not change the Product ID when creating the new Install. To create the install for the new version I copied the aip file and all my source files to a different directory then replaced the old exe with the new exe. The exes do have different version on them also. Then I create a patch for these to installs. The proplem I am having is that the patch only works 1/20 times. Every time I run the patch is says it did everything but most times all it does is change the product version of the installed app. The exe files are not replaced. When I run the patch I select Repair. I assume this is the right way to do it as it did work at first. Now all I get is the product version changing and when I try to uninstall it says network error can not find "c:\windows\installer\version1.msi" Any help on this would be great.
Brad
Suggested Articles
I created a 2 test installs that simply install a txt file then the newer version has different text. When I run the patch on these 2 it works find with a simple repair. When I click modify the Main Feature is set to install locally. However on the installs where I get the patch failure the Main Feature is set to install when needed. If I switch that to install locally then run that then open and do a repair the patch works. This seems like a convoluted way to add a patch.
Hi,
This is the way the patching is supposed to occur. When you install the first version of the MSI, Windows Installer will create a cached version of it. The patch will then modify this MSI so that it the next time a repair / modify operation is executed the patched version will be installed.
If a feature is set to install on demand the patching will occur only when it will actually get installed and not on the moment the patch is ran.
Regards,
Mihai
This is the way the patching is supposed to occur. When you install the first version of the MSI, Windows Installer will create a cached version of it. The patch will then modify this MSI so that it the next time a repair / modify operation is executed the patched version will be installed.
If a feature is set to install on demand the patching will occur only when it will actually get installed and not on the moment the patch is ran.
Regards,
Mihai
-
a_j_burgess
- Posts: 15
- Joined: Tue Oct 18, 2005 12:24 pm
Altering custom actions in MSI with Patch
I did not realise that this was the way the patching worked. That has made things a little clearer for me too.
However, my patch needs to modify one of the custom action scripts and then run it. I have tried to modify it in the 'upgraded' msi but the original script from 'target' runs. I also tried changing the name of the script in the 'upgraded' version and pointing the CA to it but then I get a message saying it cannot be found. This is contrary to what I would expect - I would expect that any new files included in the 'upgrade' would be included in the patch.
How do I go about calling a modified script or a new script altogether with my patch.
Regards,
Anthony
However, my patch needs to modify one of the custom action scripts and then run it. I have tried to modify it in the 'upgraded' msi but the original script from 'target' runs. I also tried changing the name of the script in the 'upgraded' version and pointing the CA to it but then I get a message saying it cannot be found. This is contrary to what I would expect - I would expect that any new files included in the 'upgrade' would be included in the patch.
How do I go about calling a modified script or a new script altogether with my patch.
Regards,
Anthony
Hi,
The patching should replace the source for the custom action. For that the custom action in the 'upgraded' MSI must have the same name as the one in the 'source' MSI.
The problem why it's not working could be the execution condition. If the custom action is set to run only on first install (condition: NOT Installed) it will not be executed during a patching.
Hope this helps.
Regards,
Mihai
The patching should replace the source for the custom action. For that the custom action in the 'upgraded' MSI must have the same name as the one in the 'source' MSI.
The problem why it's not working could be the execution condition. If the custom action is set to run only on first install (condition: NOT Installed) it will not be executed during a patching.
Hope this helps.
Regards,
Mihai
-
a_j_burgess
- Posts: 15
- Joined: Tue Oct 18, 2005 12:24 pm
Mihai,
thanks for the reply. The condition set on the original msi was 'NOT REMOVE~="ALL"' which I believe means that it will always run except when the product is being uninstalled. If this is not the case, is it possible to overwrite the condition with a patch?
The names of both the CA and the vbscript that is called have the same name in both and I can see that the script does run (there are certain cmd windows that are poped up). However, things that are disabled in the new version of the script still seem to run.
I had tried to rename the script that was called by the CA but, on attempting to patch I got file not found. I wondered whether this might be a clue as to what I was doing wrong in the patch configuration?
If it helps, my settings are as follows:
Allow product code mismatches
Don't remove temp folder
Include whole files only
Ignore missing source files.
Product must match base database
Don't delete PCP file
When I go to apply the patch, I select "Repair". Is this correct? The resulting entry in Add/Remove Programs does show that the version number has changed so assume so.
Many thanks - despite my postings I do find this tool very easy to use.
Regards,
Anthony
thanks for the reply. The condition set on the original msi was 'NOT REMOVE~="ALL"' which I believe means that it will always run except when the product is being uninstalled. If this is not the case, is it possible to overwrite the condition with a patch?
The names of both the CA and the vbscript that is called have the same name in both and I can see that the script does run (there are certain cmd windows that are poped up). However, things that are disabled in the new version of the script still seem to run.
I had tried to rename the script that was called by the CA but, on attempting to patch I got file not found. I wondered whether this might be a clue as to what I was doing wrong in the patch configuration?
If it helps, my settings are as follows:
Allow product code mismatches
Don't remove temp folder
Include whole files only
Ignore missing source files.
Product must match base database
Don't delete PCP file
When I go to apply the patch, I select "Repair". Is this correct? The resulting entry in Add/Remove Programs does show that the version number has changed so assume so.
Many thanks - despite my postings I do find this tool very easy to use.
Regards,
Anthony
Hi,
If the CA have the same name only one of them should run. Are those custom action installed or attached?
You should make sure that the second version of the script is ran and not the first one. For this I would suggest some debug messages.
Also, you should check the conditions for the the things that should be disabled. The conditions could became true by mistake.
Hope this helps.
Regards,
Mihai
If the CA have the same name only one of them should run. Are those custom action installed or attached?
You should make sure that the second version of the script is ran and not the first one. For this I would suggest some debug messages.
Also, you should check the conditions for the the things that should be disabled. The conditions could became true by mistake.
Hope this helps.
Regards,
Mihai
-
a_j_burgess
- Posts: 15
- Joined: Tue Oct 18, 2005 12:24 pm
Mihal,
The CAs are installed not attached (Type code 1174). The second version definitely does not run. Debug messages in the log, that only relate to first version confirms this. The 'disabled' parts are actually deleted from the new vbscript which means that, if the second version WAS run, they could never be called.
Regards,
Anthony
The CAs are installed not attached (Type code 1174). The second version definitely does not run. Debug messages in the log, that only relate to first version confirms this. The 'disabled' parts are actually deleted from the new vbscript which means that, if the second version WAS run, they could never be called.
Regards,
Anthony
-
a_j_burgess
- Posts: 15
- Joined: Tue Oct 18, 2005 12:24 pm
Hi,
I have attached a fragment of the log file where you can see that the file 'InstallerScript.vbs' is replaced by the new one. The 'images\setup\' folder is where the upgraded version is stored and they must be difference or else the AI would not have flagged it:
---START LOG---
Building package: C:\anthony\ADC 1.37 Patch 1\ADC_1_37_Patch_1.msp
Creating PCP database... done.
Creating MSP...
***** Log starting: 2005-11-09 10:41:20 *****
Input-PCP path = 'C:\anthony\ADC 1.37 Patch 1\ADC_1_37_Patch_1.pcp'
Patch-MSP path = 'C:\anthony\ADC 1.37 Patch 1\ADC_1_37_Patch_1.msp'
Temp Folder = 'D:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\~PCW_TMP.TMP\'
Patch GUID = '{E21CFB8E-586B-43CF-8A9A-B6B57184AF4E}'
ListOfPatchGUIDsToReplace = '<none>'
ListOfTargetProductCodes = '*'
PatchSourceList = 'PatchSourceList'
AllowProductCodeMismatches = '1'
AllowProductVersionMajorMismatches = '0'
OptimizePatchSizeForLargeFiles = '<blank>'
ApiPatchingSymbolFlags = '<blank>'
MsiFileToUseToCreatePatchTables = '<blank>'
SqlCmdToCreatePatchTable = '<blank>'
SqlCmdToCreatePatchPackageTable = '<blank>'
SqlCmdToCreateMsiPatchHeadersTable = '<blank>'
DontRemoveTempFolderWhenFinished = '1'
IncludeWholeFilesOnly = '1'
MinimumRequiredMsiVersion = '200'
SEQUENCE_DATA_GENERATION_DISABLED = '1'
AllowRemoval = '<blank>'
Using internal SQL cmd to create 'Patch' table.
Using internal SQL cmd to create 'PatchPackage' table.
Using internal SQL cmd to create 'MsiPatchHeaders' table.
Files differ: 'C:\anthony\ADC 1.37 Patch 1\images\setup\.\IS\IntegrationServer\support\win32\InstallerScript.vbs',
'C:\anthony\ADC 1.37 Patch 1\images\setup_1\.\IS\IntegrationServer\support\win32\InstallerScript.vbs'.
Patch API could not create a small patch; using whole upgraded file.
Including entire file: 'C:\anthony\ADC 1.37 Patch 1\images\setup\.\IS\IntegrationServer\support\win32\InstallerScript.vbs';
FTK=InstallerScript.vbs_1; temp location=Family\07930.FLE. Files differ: 'C:\anthony\ADC 1.37 Patch 1\images\setup\.\IS\IntegrationServer\packages\AAB_WoCa_GGCA\ns\aab\woca\ggca\dcm\PAYEXT\services\parseAndMapToCanonical\flow.xml',
...
<more diffs here>
...
***** Log finishing: 2005-11-09 10:49:02 *****
done.
Writing Summary Information... done.
Build finished successfully.
---END LOG---
The only thing that looks strange is the line that says:
"Patch API could not create a small patch; using whole upgraded file." but, otherthan that, I see no reason why running the new .msp file and then selecting repair, will not replace the files.
I am using Advanced Installer 3.3 so I assume that any bugs with creating patches have already been sorted out.
Help!
Anthony
I have attached a fragment of the log file where you can see that the file 'InstallerScript.vbs' is replaced by the new one. The 'images\setup\' folder is where the upgraded version is stored and they must be difference or else the AI would not have flagged it:
---START LOG---
Building package: C:\anthony\ADC 1.37 Patch 1\ADC_1_37_Patch_1.msp
Creating PCP database... done.
Creating MSP...
***** Log starting: 2005-11-09 10:41:20 *****
Input-PCP path = 'C:\anthony\ADC 1.37 Patch 1\ADC_1_37_Patch_1.pcp'
Patch-MSP path = 'C:\anthony\ADC 1.37 Patch 1\ADC_1_37_Patch_1.msp'
Temp Folder = 'D:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\~PCW_TMP.TMP\'
Patch GUID = '{E21CFB8E-586B-43CF-8A9A-B6B57184AF4E}'
ListOfPatchGUIDsToReplace = '<none>'
ListOfTargetProductCodes = '*'
PatchSourceList = 'PatchSourceList'
AllowProductCodeMismatches = '1'
AllowProductVersionMajorMismatches = '0'
OptimizePatchSizeForLargeFiles = '<blank>'
ApiPatchingSymbolFlags = '<blank>'
MsiFileToUseToCreatePatchTables = '<blank>'
SqlCmdToCreatePatchTable = '<blank>'
SqlCmdToCreatePatchPackageTable = '<blank>'
SqlCmdToCreateMsiPatchHeadersTable = '<blank>'
DontRemoveTempFolderWhenFinished = '1'
IncludeWholeFilesOnly = '1'
MinimumRequiredMsiVersion = '200'
SEQUENCE_DATA_GENERATION_DISABLED = '1'
AllowRemoval = '<blank>'
Using internal SQL cmd to create 'Patch' table.
Using internal SQL cmd to create 'PatchPackage' table.
Using internal SQL cmd to create 'MsiPatchHeaders' table.
Files differ: 'C:\anthony\ADC 1.37 Patch 1\images\setup\.\IS\IntegrationServer\support\win32\InstallerScript.vbs',
'C:\anthony\ADC 1.37 Patch 1\images\setup_1\.\IS\IntegrationServer\support\win32\InstallerScript.vbs'.
Patch API could not create a small patch; using whole upgraded file.
Including entire file: 'C:\anthony\ADC 1.37 Patch 1\images\setup\.\IS\IntegrationServer\support\win32\InstallerScript.vbs';
FTK=InstallerScript.vbs_1; temp location=Family\07930.FLE. Files differ: 'C:\anthony\ADC 1.37 Patch 1\images\setup\.\IS\IntegrationServer\packages\AAB_WoCa_GGCA\ns\aab\woca\ggca\dcm\PAYEXT\services\parseAndMapToCanonical\flow.xml',
...
<more diffs here>
...
***** Log finishing: 2005-11-09 10:49:02 *****
done.
Writing Summary Information... done.
Build finished successfully.
---END LOG---
The only thing that looks strange is the line that says:
"Patch API could not create a small patch; using whole upgraded file." but, otherthan that, I see no reason why running the new .msp file and then selecting repair, will not replace the files.
I am using Advanced Installer 3.3 so I assume that any bugs with creating patches have already been sorted out.
Help!
Anthony
Hi,
The log doesn't seem to indicate any problem. A possible cause could be that the VBS script is included in the patch but not installed when applying the patch.
Being a text file the script file doesn't have a version attached. Windows Installer might take the decision not to install it, if the installed file appears to be newer than the one in package. This is because file versioning rules are taken into consideration when applying a patch.
For more information on file versioning rules please visit:
http://msdn.microsoft.com/library/defau ... _rules.asp
To avoid the problem with unversioned files both the MSIs should be build with file hashing turned on.
Hope this helps.
Regards,
Mihai
The log doesn't seem to indicate any problem. A possible cause could be that the VBS script is included in the patch but not installed when applying the patch.
Being a text file the script file doesn't have a version attached. Windows Installer might take the decision not to install it, if the installed file appears to be newer than the one in package. This is because file versioning rules are taken into consideration when applying a patch.
For more information on file versioning rules please visit:
http://msdn.microsoft.com/library/defau ... _rules.asp
To avoid the problem with unversioned files both the MSIs should be build with file hashing turned on.
Hope this helps.
Regards,
Mihai
-
a_j_burgess
- Posts: 15
- Joined: Tue Oct 18, 2005 12:24 pm
Hi,
Thanks for that. I checked the links that you provided and can confirm that the original file has equal creation and modification dates. Both of these dates are earlier than the creation date of the new file. This being the case, the original file should be overwritten. But it isn't.
I created a test where I installed a text file and then created a patch to replace it. When I ran the patch, the text contents was replaced. This implies that my approach is correct.
With the real one though, I cannot even get new files to be added although I can see them in the cab file for the new msi.
Would it help to send the PCP file? Would you be able to diagnose the problem from that?
Regards,
Anthony
Thanks for that. I checked the links that you provided and can confirm that the original file has equal creation and modification dates. Both of these dates are earlier than the creation date of the new file. This being the case, the original file should be overwritten. But it isn't.
I created a test where I installed a text file and then created a patch to replace it. When I ran the patch, the text contents was replaced. This implies that my approach is correct.
With the real one though, I cannot even get new files to be added although I can see them in the cab file for the new msi.
Would it help to send the PCP file? Would you be able to diagnose the problem from that?
Regards,
Anthony
Hi,
After examining your files we have been able to identify the problem. The cause why the patch fails is because the two MSI are not compatible with each other.
In order for a patch operation to be successful some restrictions must be followed. This is described in AI's documentation:
http://www.advancedinstaller.com/user-g ... tches.html
This means that no file or folders should be deleted. In your case these rules are broken and that is why the patching is not successful.
Patches are suitable only in the case of small modifications in the package. Since this is not your case, I would suggest using an upgrade (changing the product code) and delivering the whole MSI package of the newer version.
Regards,
Mihai
After examining your files we have been able to identify the problem. The cause why the patch fails is because the two MSI are not compatible with each other.
In order for a patch operation to be successful some restrictions must be followed. This is described in AI's documentation:
http://www.advancedinstaller.com/user-g ... tches.html
This means that no file or folders should be deleted. In your case these rules are broken and that is why the patching is not successful.
Patches are suitable only in the case of small modifications in the package. Since this is not your case, I would suggest using an upgrade (changing the product code) and delivering the whole MSI package of the newer version.
Regards,
Mihai