I have a WiX installer which, every now and then, will produce an install package which will throw the error
"The cabinet file 'cab1.cab' required for this installation is corrupt and cannot be used. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package"
I have EmbedCab="yes" in my markup
<MediaTemplate EmbedCab="yes" />
Is there a way to prevent this from happening?
I am using WiX Toolset v3.9.1208.0
Thank you
Related
I have the following problem and I'm trying to understand what is happening. I have this code:
...
<Product Name="My Service"
Id="*"
UpgradeCode="$(var.UpgradeCode)"
Language="$(var.Language)"
Codepage="$(var.CodePage)"
Version="$(var.ProductVersion)"
Manufacturer="$(var.Manufacturer)">
<Package Id="*"
Keywords="Installer"
Description="My Service Installer"
Comments="Service Installer"
Manufacturer="$(var.Manufacturer)"
InstallerVersion="300"
Languages="$(var.Language)"
Compressed="yes"
SummaryCodepage="$(var.CodePage)" />
<Upgrade Id="$(var.UpgradeCode)">
<!-- Populate NEWERVERSIONDETECTED if there is an installed
package with the same upgrade code
and version is > the version being installed -->
<UpgradeVersion Minimum="$(var.ProductVersion)"
IncludeMinimum="no"
OnlyDetect="no"
Property="NEWERVERSIONDETECTED" />
<!-- Populate UPGRADEFOUND if there is an installed
package with the same upgrade code
and the version is between the earliest version defined
and the version being installed -->
<UpgradeVersion Minimum="$(var.FirstVersion)"
IncludeMinimum="yes"
Maximum="$(var.ProductVersion)"
IncludeMaximum="no"
Property="PREVIOUSVERSIONSINSTALLED" />
</Upgrade>
<Condition Message="A newer version is already installed.">NOT NEWERVERSIONDETECTED</Condition>
<InstallExecuteSequence>
<RemoveExistingProducts Before="InstallInitialize" />
</InstallExecuteSequence>
<!-- Step 1: Define the directory structure -->
...
<!-- Step 2: Add files to your installer package -->
...
<!-- Step 3: Tell WiX to install the files -->
...
ProductVersion and FirstVersion has the x.x.x format. Because the msi contains only 3 files I prefer to uninstall everything and put the new files in place (like a major upgrade).
Here is what it's happening:
FirstVersion is defined as "0.0.1"; I build twice my project (to generate two msi with ProductVersion "0.0.2" for the first build and with "0.0.3" for the second). When I install 0.0.3 on top of 0.0.2 everything is going smoothly. In Add/Remove Programs I see the new version installed, "My Service" is up&running in Local Services, in Program Files I see my folder containing the new files.
If I build the project with the ProductVersion 2.0.2 and 2.0.3 (same steps as the previous ones), when I install 2.0.3 on top of 2.0.2, no error pops-up, the installation finishes successfully (at least Event Viewer says so) but my folder in Program Files doesn't exist, My Service is unknown in Local Services (it will not start). The only thing looking good is in Add/Remove programs which shows me the new version 2.0.3 is installed. And another strange thing is the fact that I can uninstall my application from Add/Remove Programs successfully. No error!
So why for 0.0.x format as ProductVersion upgrading is working fine, but
not for 2.0.x?
I tried to log the output of msiexec during the upgrading, but it is too
complicated for me.
PS: do not recommend another way of implementing upgrade. I need to stick
to this code because I'm using msitools which has a lot of limitations.
The versions is right, you haven't made any mistake there.
Without a verbose log your chances to find the problem are quite small. It is not hard at all. Follow the link above and you will find examples on multiple methods to generate a log and share it with us or try to read it be yourself.
I can't seem to get wix cabinet caching to work.
I have
<PropertyGroup>
<CabinetCreationThreadCount>3</CabinetCreationThreadCount>
<CabinetCachePath>cabs</CabinetCachePath>
<ReuseCabinetCache>True</ReuseCabinetCache>
</PropertyGroup>
in the wixproj.
<Media Id="1" Cabinet="contents.cab" EmbedCab="yes" CompressionLevel="mszip"/>
<Media Id="2" Cabinet="static.cab" EmbedCab="yes" CompressionLevel="mszip"/>
in the wxs
and a component that I know 100% never ever changes marked with
<Component DiskId="2" ...
I see the cab files generated in the cabs directory, but each time I build, I see the modified time of the cab file change, which suggests that it's regenerated the cabinet instead of reusing the one from the cache.
Using Wix 3.6
How can I get this working or debug the problem further?
Are you building or rebuilding (i.e. /t:build or /t:rebuild)? The WiX import will remove generated files when rebuilding. It's also possible that this is happening even if you are simply building. Generate a verbose log by passing /v:diag to MSBuild but be sure to redirect to a file like so:
msbuild /t:build /v:diag
If that does not show the CAB file(s) being deleted, I recommend checking out http://wixtoolset.org for their support channel.
WIX MSI perMachine installer writing installed property to HKCU instead of HKLM.
One of the symptoms is that the original logic I used to detect an attempt to install an older version of the product fails because I was depending on the Installed property to get defined on a system where an install had previously been executed. Just to be clear this logic has worked in the past but now I am doing regression testing and it failed.
I edited the msi with orca and modified the launch condition that tests for this. I changed the launch condition to "Installed" and the message to "Not installed" I then ran the installer on several systems where our application is installed. If Installed were true then the installer would run but in every case the installer displayed the message box meaning that it couldn't find the registry entry.
I looked in all these systems and the "installed" registry entry was located in HKCU/Software/company/product/installed=1 instead of in HKLM.
Also this is a 64 bit installer and when I run the installer it gets into the UI and I look at the task manager to make sure it is running the 64 bit version of msiexec which it is.
Here's the relevant WIX fragment which stopped working. See the 1st launch condition. I am adding the beginning of the Product ... section.
<Product Id="*"
Name="$(var.ProductDisplayName)"
Language="1033"
Version="$(var.OurVersion)"
Manufacturer="$(var.ProductAuthor)"
UpgradeCode="$(var.ProductUpgradeCode)">
<Product Id="*"
Name="$(var.ProductDisplayName)"
Language="1033"
Version="$(var.VayTekVersion)"
Manufacturer="$(var.ProductAuthor)"
UpgradeCode="$(var.ProductUpgradeCode)"
>
<Package
Description="$(var.ProductDisplayName)"
Comments="$(var.ProductDisplayComment)"
Manufacturer="$(var.ProductAuthor)"
InstallerVersion="301" Compressed="yes"
Platform="$(var.Platform)"
InstallScope="perMachine"
InstallPrivileges="elevated"/>
<Upgrade Id="$(var.ProductUpgradeCode)">
<UpgradeVersion Minimum="$(var.OurVersion)"
IncludeMinimum="no"
OnlyDetect="yes"
Property="NEWERPRODUCTFOUND" />
<UpgradeVersion
Minimum="07.01.01001" IncludeMinimum="yes"
Maximum="$(var.OurVersion)" IncludeMaximum="no"
Property="PREVIOUSVERSIONSINSTALLED"/>
</Upgrade>
<InstallExecuteSequence>
<RemoveExistingProducts After="InstallFinalize"/>
</InstallExecuteSequence>
<Condition
Message="A later version of the product is already installed. Setup will now exit.">
(NOT NEWERPRODUCTFOUND) OR (NOT Installed)
</Condition>
After I stared at the code a while I removed the "NOT Installed" logic and left
NOT NEWERPRODUCTFOUND
This isn't ideal but it works in most situations.
Anyone have an idea why the registry entry is getting placed in the wrong hive?
An MSI package is per-machine when the ALLUSERS property is set to "1". In the WiX toolset, you can set this using the Package element InstallScope attribute is set to "perMachine".
Also, upgrades will not detect packages in the other install scope. In other words, per-machine cannot upgrade per-user and vice versa.
PS: "NOT Installed" in a LaunchCondition is a very strange thing to see. That would just try to block repair/uninstall.
Moving to WiX 3.6, I'm trying to make use of burn features to ease potential download/install of required pieces, such as a specific VC++ runtime.
I started small with just some "test.wxs", see below, which is OK for candle.exe:
$ candle test.wxs
Windows Installer Xml Compiler version 3.6.3303.0
Copyright (C) Outercurve Foundation. All rights reserved.
test.wxs
But light.exe chokes on it:
$ light test.wixobj -ext WixBalExtension
Windows Installer Xml Linker version 3.6.3303.0
Copyright (C) Outercurve Foundation. All rights reserved.
light.exe : error LGHT0103 : The system cannot find the file '' with type ''.
Could someone help with this (rather cryptic) error message?
It seems related to RemotePayload, since a modified version with local file works correctly. However, I'd like to save on package size and leave the downloading on the target machine if so needed.
Full content of "test.wxs" was:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Bundle Version="1.0.0.0"
UpgradeCode="e349236d-6638-48c5-8d8b-db47682b9aeb">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />
<Chain>
<!-- C++ Runtime -->
<ExePackage Name="vcredist_x64.exe"
DownloadUrl="http://www.microsoft.com/en-us/download/confirmation.aspx?id=2092" >
<RemotePayload CertificatePublicKey="F321408E7C51F8544B98E517D76A8334052E26E8"
CertificateThumbprint="D57FAC60F1A8D34877AEB350E83F46F6EFC9E5F1"
Description="Microsoft Visual C++ 2008 Redistributable Setup"
Hash="13674C43652B941DAFD2049989AFCE63CB7C517B"
ProductName="Microsoft Visual C++ 2008 Redistributable"
Size="4961800"
Version="9.0.30729.17" />
</ExePackage>
</Chain>
</Bundle>
</Wix>
Partial answer to my own question:
The error message disappears if I add the attribute Compressed="no" to the ExePackage element.
Documentation about "Compressed" attribute says: "Whether the package payload should be embedded in a container or left as an external payload" and its value can be "yes", "no", or "default".
Using "yes" or "default" triggers the error message. Using "no" doesn't.
I had the same trouble with another package (the .NET framework) and Wix 3.7. I used the Wix source code to find the appropriate package names and registry keys to test, and then pasted the relevant bits into my installer. Then, I intentionally set 'Compressed="yes"' because I wanted to embed the file in my installer instead of having it downloaded.
There was a report similar to yours posted in this mailing list thread:
Benjamin Mayrargue: If an ExePackage has a DownloadUrl and Compressed is set to yes, light failed with error LGHT0103: The system cannot find the file '' with type ''.
Markus Wehrle: Ok, I see. If you want to have the ExePackage compressed into your bootstrapper.exe (compressed="yes") you need to specify it using "Source" attribute. Cause it will be compressed into your boostrapper during compile time, you must not declare a DownloadUrl. If you specifiy compressed="no" your ExePackage gets downloaded from the DownloadUrl during the installation of your boostrapper.
Rob Mensching: More specifically, you cannot use RemotePayload element and Compressed='yes' on the ExePackage element together. That doesn't make sense and the bug here is that the compiler didn't give you an error message here saying that.
So yes, you've correctly identified the same fix to the problem.
The Compressed attribute, by the way, specifies 'Whether the package payload should be embedded in a container or left as an external payload.' That external payload can either be a RemotePayload or another file on the disk, but the typical setup is a single bootloader with all the resources embedded into it.
Using yes for the Compression attribute will allow your application and the VC++ runtime to be installed even if the user has a slow or nonexistent Internet connection. Remove the DownloadUrl and RemotePayload from your installer, and replace them with just Compressed="yes" like this:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Bundle Version="1.0.0.0"
UpgradeCode="e349236d-6638-48c5-8d8b-db47682b9aeb">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />
<Chain>
<!-- C++ Runtime -->
<ExePackage Name="vcredist_x64.exe"
Compressed="yes">
</ExePackage>
</Chain>
</Bundle>
</Wix>
Then download the vcredist_x64.exe file (yourself, once) and place it adjacent to your test.wxs file. Adjust 'Name' if you want it in a different location. Note that this will increase the size of your resulting bootstrapper by about the size of vcredist_x64.exe, so it's not a good idea if your users will be downloading your installer.
In my case the error was thrown because the filename/directory path was over 255 characters. The file exist yet the compiler is stating that the file doesn't exist.
I have a product that used to ship with a .vdproj installer. In the most recent version, I shipped a beta with a completely redone installer using WiX (as part of the move to Visual Studio 2012, which no longer supports .vdproj). Unfortunately, at the time I didn't know that the upgrade code was supposed to be consistent across copies, and already shipped one beta installer with a different upgrade code.
I would like my installer to automatically remove previous versions built with the .vdproj installer, as well as the version that was shipped as a beta copy. This is where I've gotten so far:
<Product Id="{A4CBA9F9-D86B-400C-BD23-996B4367931A}" Name="Foo Viewer" Language="1033" Version="6.0.1.0" Manufacturer="Foo Corporation" UpgradeCode="43e024b8-b3ea-40a3-a854-2af83f207f0f">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<MediaTemplate EmbedCab="yes" />
<Feature Id="FOOVIEWERFeature" Title="Foo Viewer" Level="1" Description="The Foo Viewer GUI and CLI binaries." AllowAdvertise="no" Absent="disallow" Display="expand">
<!-- Stuff -->
</Feature>
<PropertyRef Id="NETFRAMEWORK40CLIENT" />
<Condition Message="Foo Viewer requires the .NET Framework 4.0 Client Profile or higher to run.">Installed OR NETFRAMEWORK40CLIENT</Condition>
<Property Id="WIXUI_INSTALLDIR" Value="INSTALLFOLDER" />
<UIRef Id="FooViewerInstallerUI" />
<UIRef Id="WixUI_ErrorProgressText" />
<Icon Id="FooViewerIcon" SourceFile="../FooViewer.ico" />
<Property Id="ARPPRODUCTICON" Value="FooViewerIcon" />
<!-- I got this upgrade code by opening one of the old .vdproj MSIs in Orca -->
<Upgrade Id="{80539F30-8176-4DCC-A102-ED32A34A91CB}">
<UpgradeVersion OnlyDetect="no"
Minimum="0.0.0.0"
IncludeMinimum="yes"
MigrateFeatures="no"
IgnoreRemoveFailure="no"
Property="UPGRADE_VDPROJ_FOOVIEWER"
/>
</Upgrade>
<Upgrade Id="{43e024b8-b3ea-40a3-a854-2af83f207f0f}">
<!-- Foo Viewer 6.0.0.0 (Beta) shipped with a version 5.3.0.0 in the installer. -->
<UpgradeVersion OnlyDetect="no"
Minimum="5.3.0.0"
Maximum="5.3.0.0"
IncludeMinimum="yes"
IncludeMaximum="yes"
MigrateFeatures="yes"
IgnoreRemoveFailure="no"
Property="UPGRADE_WIX_FOOVIEWER"
/>
<!-- Detect newer versions -->
<UpgradeVersion OnlyDetect="yes"
Minimum="6.0.1.0"
IncludeMinimum="no"
Property="NEW_VERSION_FOUND"/>
</Upgrade>
<Condition Message="A newer version of Foo Corporation Foo Viewer is already installed.">
Installed OR NOT NEW_VERSION_FOUND
</Condition>
<InstallExecuteSequence>
<RemoveExistingProducts Before="InstallInitialize" />
</InstallExecuteSequence>
</Product>
However, despite putting in a <upgrade> element for the old installer's upgrade code, the old version isn't getting removed. As a result the new copy tries to install on top of the old copy, and then neither version works any longer.
The detection of the beta copy, and of newer versions, works correctly (the <Upgrade with GUID {43e024b8-b3ea-40a3-a854-2af83f207f0f} ). The beta version gets uninstalled, and if I generate a "newer" installer, then the current installer correctly doesn't install. That is, the WiX installers have no problem detecting each other.
Is there something I did wrong here that won't let it detect the old .vdproj installed copies?
EDIT: I tool a log of the installation process when this happens, I get the following:
Action start 17:25:47: FindRelatedProducts.
MSI (c) (10:B8) [17:25:47:269]: FindRelatedProducts: current install is per-machine. Related install for product '{2024FF03-D6F2-4065-A22B-80252B2A66B6}' is per-user. Skipping...
Action ended 17:25:47: FindRelatedProducts. Return value 1.
which appears to be accurate. The old installer gave an option for "Per User" or "Per Machine", whereas the new installer always forces per machine. If I select "Everyone who uses this computer" in the old installer, then the new installer is able to detect it. I would like to detect either option if possible in the WiX.
I'm afraid you can't deal with 2 different existing installations at the same time in single installer. Moreover you shouldn't try to run uninstallation of another product (since your UpgradeCode and ProductCode are different, it is anoter product) because msi can't work with simultaneous installations.
What I would recommend is creating separate exe application (bootstrapper), which will run child uninstallation processes of previously installed products and then immediately run your product's installation (probably in full UI mode).
To uninstall the product with no user interaction, use the following command:
msiexec /x {ProductCode} /qn
I hope you know the ProductIds of the previously installed products. If not, you can find it, searching the registry:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\{ProductCode}\DisplayName
and HKEY_CURRENT_USER if application was installed for single user.
{ProductCode} mentioined in registry path is GUID which is your productCode. You should retrieve all nodes in "Uninstall" branch and find those which are your products checking the "DisplayName" attribute. I hope you know at least the name of the products installed =). And be careful not to delete all software on client's machine =)
Please note if you installed x86 application on x64 machine, you should search location
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{ProductCode}\DisplayName"
One more important notice: if your bootstrapper will be also x86 application, you should retrieve node without "Wow6432Node" node because it will be automatically inserted in the requested path. Wonderful world of registry keys on different platforms =).
Please ensure your bootstrapper will be run with admin permission or will ask permission elevation (it should contain security manifest).
One assumption about problem in your post: maybe you didn't change the ProductCode when changed the UpgradeCode? I'm not sure how it will behave, but it is definitely not a MajorUpgrade which automatically removes the previously installed product. For more details see Wix documentation on upgrades. So you might got Minor upgrade or patch which directly installs new components on top of the previously installed files. That definitely could break the application.