One of the things that I have been pestering the SQL team to do is to name their updates according to what is contained in them. For example, instead of just:
sqlncli.msi
What I'd prefer is that the file was called something like:
SQLServerNativeClient2k8SP1CU3x64.msi
So I normally rename them as soon as I receive them, to avoid confusion in future. However, today I found that doing so caused me a problem. After renaming the file, and installing it, the installation failed with the error:
"A network error occurred while reading from the file: C:\temp\sqlncli.msi"
A quick inspection of the error shows that the code in the msi is looking for the file by name. Renaming the file back to the original name makes it install ok. It's a pity that the person coding the installer didn't pick up the name of the file programmatically, rather than hard-coding it.
Anyway, hope that helps someone that sees this error.
Good to know! I also have the same habit of renaming those files.
This behavior is actually inherent to Windows Installer itself, not to the way that particular MSI was programmed. The name of the MSI file must remain the same as long as the ProductCode is the same, and the ProductCode can only be changed when doing a major ugprade (in the Windows Installer sense). There is an old MSDN blog post at http://bit.ly/tfpUvK that discusses part of the reasoning for this.
Microsoft actually did use (slightly) more descriptive names when they originally posted some of the 2008 RTM release "Feature Pack" downloads years ago, but still used the generic names on the 2008 installation media. This lead to the same error you encountered for anyone who installed those downloads from the Feature Pack and then later tried to install SQL Server 2008 itself. I filed a bug on Connect about it (https://connect.microsoft.com/SQLServer/feedback/details/362062), and Microsoft eventually renamed the downloads to use the same generic names as were on the installation media.
Interesting Kevin. That's a real pain. The silly thing is that it doesn't cause an issue for most installers that I have.
I ran into this issue with some third party software. They unpacked files from a setup.exe and ran the SQL native client installer – x86 or x64 – appropriately.
I apparently was the only person who had run into it so far. The fix was easy – grab the extracted temp files from setup.exe, copy the file myself to sqlncli.msi (their version of the name had to stay too) and all was good.
I'm not sure, but it might be more of an issue if you already have an older sqlncli installed (I think that's why I ran into the issue when others had not yet)… Probably cracking it open with Orcas would highlight the issue – wonderful tool to fix bad installers 🙂
Found some more into today, courtesy of the SqlLocalDB folk: http://blogs.msdn.com/b/windows_installer_team/archive/2006/05/12/595950.aspx
Not renaming the installer is indeed an msi rule. For that reason, when they ship both 32 bit and 64 bit versions of SqlLocalDB, they'll both have exactly the same name. They suggest putting each in a different folder.
It still seems silly to me to have to do it this way. Surely, the file that is shipped doesn't have to be the actual msi.
So what I think I'll do in future is to zip the actual msi into another file that indicates what the file actually is.