I'm attempting to automate a roundtrip install and uninstall of a set of MSI files (generated by WiX) from a pack of sample programs. For some reason, a .MSI file that's perfectly happy to install on a double click generates:
This installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package.
when I invoke it with MSIEXEC in the following manner:
<ItemGroup>
<_SampleMsi Include="$(_ArtifactsPathAcceptanceSamples)\**\*.msi" />
</ItemGroup>
<Exec Command="$(WixDir)\smoke "%(_SampleMsi.Identity)""/>
<!--Guarantee precondition even if cleanup didn't work-->
<Exec Command="msiexec -passive -norestart -x "%(_SampleMsi.Identity)"" IgnoreExitCode="true" />
<Exec Command="msiexec -norestart -i "%(_SampleMsi.Identity)"" />
<!--Uninstall of every sample should also always work-->
<Exec Command="msiexec -passive -norestart -x "%(_SampleMsi.Identity)"" />
The same problem also happens when I try to uninstall based on the Product Id GUID:-
msiexec -passive -norestart -x FC7445BB-7E1D-4E36-A42A-CFA56263E453
What gives?
Do not take the text of the message literally. About all you should be concluding is that misexec is treating some part of your command as a filename, and it didn't get to load and process the entirety of it to its satisfaction. Whether that's because the path was too long, permissions were refused, or any number of other conditions only limited by your imagination (most of the KB articles appear to pertain to Installer cache issues, which is generally the GUID-based syntax or patching/upgrading options)
You're missing the braces from the GUID, fool. I mean, you did know there are braces on the GUID even if msiexec /? doesn't tell you or show you, right?!
i.e. you need to replace FC7445BB-7E1D-4E36-A42A-CFA56263E453 with {FC7445BB-7E1D-4E36-A42A-CFA56263E453}
(I had stopped trusting/reading the outputs and was considering it a possibility that the GUID was resolving to a cached MSI which msiexec was unhappy with for the same reason that it appeared to be unhappy with the installation syntax which is what all the KB articles in this space tend to talk about.)
Your path contains relative jumps which, despite having a net length of <160 chars, have a gross length >160 chars so the underlying file APIs are choking. People like writing generic error messages that are misleading.
You can fix it by replacing Identity above with FullPath in each batching expression used.
Another way to remedy it is to use a WorkingDirectory with the Exec of msiexec