About Windows Installer, the .NET Framework, and Visual Studio.
Windows Installer relies on structured storage for information about the installation package and to store data used by the installation such as any Binary types and cabinet files. Patches (.msp files) are no different in structure but will contain different data.
Up until Windows Installer 3.0, patches themselves didn't contain any standard tables but could contain user tables. For Windows Installer 3.0 the tables MsiPatchSequence and MsiPatchMetadata could be added as meaningful tables. What patches have always contained, though, was a set of sub-storages for each transform that transforms the target installer package (.msi file) to the upgraded installer package, and possibly a stream for a single cabinet file that contained the patched files, either in whole or in part as delta patches. Like all Windows Installer files, patches also contain a summary information stream, but some properties mean different things like the Revision Number summary property which contains only the patch code prior to Windows Installer 2.0, and contains the patch code followed by a list of patch codes to obsolete.
The transforms embedded in patches contain all the differences between a certain target and upgrade package. If you're using PatchWiz.dll, a transform is created for each corresponding row in the TargetImages and UpgradeImages tables. If you use a SQL expression to select from the temporary _Storages table you can enumerate all sub-storages within the package, which will list two transforms for each corresponding target and upgrade package. One transform is the actual difference between the target and upgrade packages, while the other transform beginning with '#' adds entries to the Patch, PatchPackage, Media, InstallExecuteSequence, and the AdminExecuteSequence tables. This transform is not applied to administrative installation images because the patch is merged directly into the installer package so no patch-specific data is required.
Below you can see a basic representation of an MSP file, though an MSI, MSM (merge module), or PCP (patch creation properties) file has the same structure though they don't typically contain transforms but can.
I am often asked why file changes don't appear in the handy Windows Installer tool, Orca. When people
Visual Studio 2005 Service Pack 1 can take a long time to install and may apply to multiple products
Transforms can change just about anything in an installation package - even the code page. Transforms
I have created a patch (.msp) file using msimsp
The patch is working fine for 32-bit OS (I used Win 2003)
But the same patch installation failed on 64-bit OS (Win 2003 x64, Win7 x64)
The patch throws following error
Error 1334.The file 'abc.dll' cannot be installed because the file cannot be found in cabinet file 'PCW_CAB_Family00'. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package.
can you please give any comment on this ?
@Digambar, there's not enough infromation to go on. If you could post a verbose install log online and share with me the URL I can have a look. Are you patching the same product on both 32- and 64-bit OSes? (I.e., same product installs on both platform architectures, or do you have separate products for each platform.)
I created patch using msimsp.exe with one row in each of UpgradedImages and TargetImages tables. The MSI was built for all languages which means that both (target / upgraded) Msi's were accompanied by <Lang ID>.mst files for each language. On applying the patch I observed that english strings from upgraded MSI are being shown in PatchWelcome screen but German strings from 1031.mst are not shown.
1. I understand that upgraded and target msi's have English strings so final patch should have the delta of English language only so its working properly for English language. But when same patch is used to upgrade German installation, where from where does it show PatchWelcome sceen in German?
2. I even deleted c:\windows\installer\<Product Code>\1031.mst but still the patch shows PatchWelcome screen properly in German. Does the patch store the localized strings or it picks from cached msi?
3. If patch stores the localized strings then why doesn't it store from upgraded image rather than target image?
4. Do I have to provide MSIs for all languages in upgradedImages and TargetImages tables to resolve this problem?
5. Can I make a single patch for two different products say A.msi and B.msi?
thanks for helping
@Dinesh, never delete files directly from the Installer directory like that. I've blogged before how removing some files from sub-directories are fine, but by removing that MST you may have corrupted your installation and possibly the machine.
MST applied during the initial installation as secure transforms are cached. Those will be used for each future transaction. If you apply an MST later, they will not be cached nor used.
Your MSP, as you noted, only includes diffs. So if you install the DEU MSI and the patch - and the patch contains no changes to strings - the DEU strings are still used from the MSI. However, since you said you built the MSP from the diff of the two ENU MSIs and it applies to DEU - likely that means you didn't create unique MSIs for each language which you absolutely should do (meaning separate ProductCodes), and the MSP should target the ProductLanguge anyway, which is the default for PatchWiz/msimsp.
Since that doesn't seem to be the behavior as you documented, I can't really say exactly what the issue is or even if there is one.
So, yes, you should provide MSI pairs for each language in the Target and UpgradeImage tables, but make sure they have unique ProductCodes, ProductLanguage, and probably UpgradeCodes as well (depending on whether they "upgrade" each other so that only one language is ever installed, which some products like SQL will do). A single MSP can target all of those, or even a completely separate product.
I would recommend, though, that you use the <Patch> element/feature in WiX v3.5 that has been released at RTM quality, or the recently released RC for WiX v3.6. This patching infrastructure is much easier to use, works with MSIs, prevents bad situations unlike PatchWiz (which lets mistakes happen that can be very difficult to diagnose), and even lets you more easily filter which resources you want updated if you don't want to update everything (which is still possible). See http://wixtoolset.org for more information.
We are facing some issue while trying to install MSP on few 64 bit machines. It was successfully installed on most of the 64 bit machines.
Both MSI files generated using Visual Studio 2008 Enterprise.
When I install the patch the event log says,
Product: Web Client -- Error 1334. The file '_D744881C0490C5CD98D2C6534ED445FA' cannot be installed because the file cannot be found in cabinet file 'PCW_CAB_Family00'. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package.
Product: Web Client - Update 'Web Client - APM 12.6.05' could not be installed. Error code 1603. Additional information is available in the log file C:\Users\ADMINI~1\AppData\Local\Temp\MSI33ef7.LOG.
It would be great if you can let us know the possible causes & resolution for this issue.
Thank you very much.
@Rajesh Banuka, there's really not enough to go on. How was the MSP produced? Did you install a previous version on some of these machines and didn't change the patch code?