First time using the WiX install project in VS 2008 for me, and its been interesting. I like it over all, but I do miss the automation of the standard Visual Studio installer project.
I did run into an aggravating issue that I managed to figure out a solution for. I present it here for your edification.
E_FAIL == Epic Fail?
After working hard at getting my WiX project to successfully install a simple website, I was feeling pretty good about it. But the next time I loaded up Visual Studio and opened my solution, I got the following error:
Error HRESULT E_FAIL has been returned from a call to a COM component.
That was helpful. After Ok-ing the dialog away, I saw that my WiX project was grayed out and marked unavailable. Super. I tried a number of different things:
[more]
- Google (some valid results, no resolutions)
- Reinstall WiX
- Repair WiX
- Process Monitor (nothing stuck out)
- fuslogvw (nothing)
- Regedit (registry keys pointed to the right assemblies in the right locations)
- Wondered aloud if there was a tool for debugging COM calls
- Prayer (was informed I had to help myself)
While delving into regedit I noticed that WiX was developed using the Visual Studio SDK. So, I did a quick search for known issues and found a great blog post over at the VSX Team Blog. It listed known issues with version 1.0 of the SDK. Nestled gently within, like a baby nuzzling his mother’s breast, I found what I thought was the answer:
When creating a new project using a name that exceeds 28 characters, the project works properly until “devenv.exe /setup” or “devenv.exe /remove” is called during installation, repair, or uninstalling the package. To prevent an error from occurring, all project names should contain 28 characters or less.
My project name definitely had more than 28 characters (yes, its a weakness of mine). I immediately created a new install project with a short name, moved everything over from the old install project to the new, realized that I probably could have just renamed the project (aaah, screw it), and saved everything. In order to get the error you have to open the solution, so I closed it and reopened it. And what do you know, it worked!
Wrong.
Well, at least I thought it worked. It turned out I was mistaking a side effect of my attempts to fix the problem with the solution I was testing. The real issue was with subdirectories. The docs say you should create a Bitmaps directory under the solution and place any of your icons and bitmaps for your UI there. My tests would work up until the point I recreated this file structure in my project. In other words,
This is good:
TL;DR
If your VS 2k8 WiX 3.0 project is broken (unavailable), flatten the directory structure of your project (subfolders are bad, mmmkay?) and, just in case, make sure your project name is less than 28 characters long.
![image[3]](http://statestreetgang.azurewebsites.net/wp-content/uploads/2008/05/image31.png)
![image[3]](http://statestreetgang.azurewebsites.net/wp-content/uploads/2008/05/image32.png)
What build of WiX do you have? I fixed a Votive bug very similar to this about a month ago. The latest build handles subfolders just fine.
Its version 3. The binaries all show version 3.0.3829.0 except for mergemod.dll which is 3.0.3790.371 and mspatchc.dll is 6.0.6000.16384.
Yes, that bug was active in Votive for just a couple weeks, and you happen to have a build that has it. It was soon fixed, so if you upgrade to a recent build you shouldn’t have that problem anymore.
Note this was a bug in Votive and not an issue with the VS SDK that Votive is built on top of.