views:

104

answers:

1

We're using Visual Studio 2008's Setup Project to create an installer for our .NET 3.5 app. We host the .exe and .msi files on a website for our client to access, and produce new ones regularly to provide updates.

This has all been fine until recently we've noticed some cases where installing via the .exe fails. The symptoms are: The .exe downloads fine, and runs fine. It appears to download the .msi successfully (the "downloading application files" step plods through happily), but then when it gets to the end of the "preparing to install" step, instead of launching the installer UI it pops up a message saying "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".

You'd think that the .msi is just corrupt or something, but running it explicitly (even downloading it from the same location as the .exe to do so) works just fine.

This problem is occurring on just some of our machines, which are running a mixture of XP and Windows7. The only pattern I can see in those machines that experience the problem is that they tend to have had the application installed on them longer (i.e. updating the app rather than installing for the first time).

It seems to me that it might be something to do with how/where the .exe downloads the .msi to, and perhaps different versions are conflicting there?

Has anyone experienced this before? Does anyone know where the installer .exe puts the .msi that it downloads?

A: 

I've seen this in the past where ISPs are corrupting the download, often in the case where a small EXE then downloads the MSI. The solution for us in this instance was to provide a single compressed installer which didn't download the MSI separately.

We've also encountered similar problems with other products when ISPs are corrupting the digital signature on Firefox Extensions (.xpi files)

sascha
Thanks for the reply, and the suggestion of a single installer file - I'll look into that.We found that antivirus (we use ESET NOD32 v4 ourselves) was a contributing factor, and disabling this allowed the installer to run successfully.We'd still like to get to the bottom of it though, as we can't really recommend disabling AV as a long-term solution.
Moik
I'd take that up with the antivirus vendor, sounds like a definite bug.
sascha