Don’t you just love it when major software manufacturers change their product installations without giving any thought to how Windows installation developers are going to incorporate their installations into a larger installation?
Over the years, I have installed SQL Server from installations more times than I can count. Recently, I had two clients that needed SQL Server 2014 Express installed. For the first client, I thought, “Okay, SQL Server is a pain, but I can always get an installation to work without too much trouble.” Boy, was I wrong. It was a nightmare.
On the second client, I thought, “Hey, I’ve done this before. I’ll just use what I learned the first time, and this will go much quicker.” I was wrong again. It seems like every time you need to install SQL Server, it’s going to get you somehow. Here’s why the 2014 version is such a nightmare.
Microsoft has changed the way the SQL Server 2014 Express installation works. I don’t know if it was intentional, or whether they just didn’t think through the ramifications for installation developers. But, it works differently than in the years past.
Up to now, you would just run the .exe in the SQL Server prerequisite, the files would be extracted on the user’s machine, and then the installation would run, all in the same step, and all silently. But no more.
When you extract the files, it brings up a dialog asking you where to put the extracted files. What this means is that you can no long extract the files and then run the installation in the same step.
I tried multiple methods, but in the end, I had to extract the files first, then add the extracted files to the prerequisite. Sounds like no big deal, right? But, this is a big problem.
The first client wanted a small footprint, so including both the x86 and x64 prerequisite files for SQL Server 2014 Express made the installation too big. Therefore, I had to create two projects, one for the x86 version of SQL Server, and one for the x64 version.
I also had to use the Advanced UI/Suite project because I needed to get a SQL Server password from the user. And there is no way to pass a parameter to a prerequisite when using a Basic MSI or InstallScript MSI project.
In the Suite project, you can create a wizard page that asks the user for a password, and the value is stored in a property. You can then pass this on the command line to the SQL Server package in the Suite and it will use that password when the installation is performed.
My first client also wanted an installation that downloaded the prerequisites from their server. This also didn’t work with SQL Server 2014 Express in a Suite project. It’s because when the SQL installation is run, it runs some other files, and the installation is then returned back to the Suite before the installation of SQL has actually been performed. When this happens, the Suite thinks the SQL installation is finished, when in reality, it has just started. Therefore, I could not do a Suite install where the SQL prerequisite files were downloaded from a server.
For my project requirements, the only way to do the installation was to have the user download the completed x86 or x64 Suite installation first, then run the installation from their machine.
For the second client, I thought I could use the same method as with the first client, but they didn’t need input from the user to be passed on to the SQL Server installation. I did try the Suite method first, but it’s very tricky to get the Detection and Eligibility conditions correct. Rather than spend a lot of time on it, I switched to an InstallScript MSI project.
Using InstallScript MSI, you can install SQL Server with LaunchApplication() from the script. Just make you do it from OnFirstUIAfter(). Don’t try it from OnFirstUIBefore(). It won’t work.
Knowing these things should save you a lot of time.