What can cause MSIExec Error 1619 'This installation package could not be opened'

Question

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 &quot;%(_SampleMsi.Identity)&quot;"/>
<!--Guarantee precondition even if cleanup didn't work-->
<Exec Command="msiexec -passive -norestart -x &quot;%(_SampleMsi.Identity)&quot;" IgnoreExitCode="true"  />
<Exec Command="msiexec -norestart -i &quot;%(_SampleMsi.Identity)&quot;"  />
<!--Uninstall of every sample should also always work-->
<Exec Command="msiexec -passive -norestart -x &quot;%(_SampleMsi.Identity)&quot;" />

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?

Ditter

Answer 1

1. 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)

2. 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.)

3. 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

Ditter

Looks like you started typing the answer to your own question right after you published the question :-) – Paraph

@YanSklyarenko Yes, you caught me :D it was either stick it here or stick it on an internal wiki. I find it incredible how little info is out there on msiexec spelunking. Seems all that 'obvious' troubleshooting stuff lives in the minds of the few installer experts out there... – Ditter

msiexec /i .\MyFile.msi doesn't work, because of the .\ Which idi*t at MS wrote this program anyway? – Stated

@HaiPhan perhaps you could work around by passing only the filename and then putting the path into the Exec's WorkingDirectory might let you handle this ? – Ditter

Oh, I'm only complaining, heheh. msiexec /i MyFile.msi works just fine. But I was using tab completion, which automatically adds the .\ – Stated

Friggin missing braces on the GUID. Who would have thought? – Byington

Answer 2

Just removed .\ prep-ending the filename and it worked.

Convery

weird - that fixed my problem as well – Marienbad

I hate Windows sometimes... Why did this work?! – Morpheme