WiX Toolset v3.6 Failed to Install
Although the final version of WiX v3.6 has just been released, this wasn't the first time I tried installing it - I already had mixed experience from before.
As a satisfied user of WiX v3.5 I first tried installing it when it was still in beta because I needed a bootstrapper for the setup I was working on and the new Burn feature seemed a perfect match. Having problems installing it with its setup which was clearly done in Burn put me off, though. I didn't even want to investigate what went wrong: why would I depend on beta software if it didn't even work on my machine. Instead I decided to modify and use the C++ bootstrapper that came with WiX v3.5. I did have to refresh my knowledge of C++ a bit and I did spent quite some time making sure it builds on the build server, but it worked flawlessly ever since and I don't regret this decision.
A couple of months later, when WiX v3.6 release candidate was available I finally switched to it after encountering a bug in WiX v3.5 which was only fixed there. Fortunately this time the installer just worked, even for me. Testing also showed that the bug was indeed fixed and no new issues were encountered. It worked for me since then without problems.
Today I was setting up my new Windows 8 based development workstation and noticed that the final version of WiX v3.6 has been released yesterday. Without any second thoughts I decided to install it only to find out that setup procedure failed for me once again just like it did during beta: with a short non-descriptive message and no additional information immediately available. This time I had to get to the bottom of it, though: WiX v3.5 is not an option any more and I really didn't want to settle with the release candidate if final release is already available. Although I didn't try, the setup for release candidate could fail just as well.
The first step was finding out what exactly failed. The log would be a perfect place for that, but I had no idea how to enable it from the provided bootstrapper. I found out it's enabled by default and written to a file named WiX_Toolset_v3.6.3303.0_###.log in %TEMP% where ### is replaced with a current timestamp. Peeking into it I quickly found the culprit:
[0A5C:1118][2012-09-04T08:23:42]: Prompt for source of package: ProjectAggregator2,
payload: ProjectAggregator2, path: C:\Users\DamirA\Downloads\ProjectAggregator2.msi
[0A5C:1118][2012-09-04T08:23:42]: Failed to resolve source for file:
C:\Users\DamirA\Downloads\ProjectAggregator2.msi, error: 0x80070002.
[0A5C:1118][2012-09-04T08:23:42]: Error 0x80070002: Failed while prompting for source
(original path 'C:\Users\DamirA\Downloads\ProjectAggregator2.msi').
[0A5C:1118][2012-09-04T08:23:42]: Failed to acquire payload:
ProjectAggregator2 to working path: C:\Users\DamirA\AppData\Local\Temp\
{d8b4d69d-4ed2-4fc3-a6ad-26cab0e7da1d}\ProjectAggregator2, error: 0x80070002.
[0A5C:1778][2012-09-04T08:23:42]: Error 0x80070002:
Failed while caching, aborting execution.
I certainly wasn't the first one having problems with ProjectAggregator2.msi. It might have been the reason behind my failed installation of beta as well. This time I solved the problem by putting ProjectAggregator2.msi in the same directory as WiX36.exe where it seemed to be looking for it. I still had to find it first and this post was very helpful with that. The setup is supposed to be looking for it here. Or at least it did so once since this URL wasn't listed in my setup log at all. Anyway, after downloading it manually and putting it in the right location, the installation finally succeeded and I could continue setting up my machine.
Still, the bitter taste stayed in my mouth. I'm all for having a simpler and better looking setup experience, but not at the cost of its reliability. I'm pretty sure the problem is not directly related to Burn (I guess Visual Studio 2012 setup is using it as well and I definitely can't complain about that experience). It was just the tool used to design the new, not so perfect, setup which leaves the user even more helpless when something goes wrong than a standalone msi would.
UPDATE: As Rob mentioned in the comments, the bug is already fixed.
