I am very much looking forward to the release of Visual Studio Rosario. The list of major features is available here. On the list is the integration of WiX. Rob Mensching posted about this back in November. This really validates the work that Rob and his team have done (congratulations to them), and enforces the position many adopted when we took the risk to develop our commercial products’ installers with the toolset.
Rob mentioned that code changes made by the Visual Studio team would be checked back into the WiX trunk. I was curious about the progress on WiX in Rosario so I downloaded the November CTP VPC. I was a bit disappointed when I saw that at the moment, it is just Votive installed as in Visual Studio 2008, but it is very early days.
I am hoping that the Visual Studio team would take WiX in a similar way that they did with FxCop and Code Analysis. I still think it should be called WiX in Visual Studio, but I would like it to be a first grade component, rather than a latecomer tack on. The difference between the integrated version and the sourceforge hosted version should be very simple, WiX project types should be within Other Project Types > Setup and Deployment and different product/upgrade GUID’s.
Christopher Painter said there is a huge gap in the authoring/designer/editing tools for WiX, which is completely correct. I think Microsoft considering to purchase a current tool and integrate that might be a good way to go, but I think Microsoft already has code, mostly from the current Visual Studio Setup projects, for the critical features that are required.
1. Enabling automatic file references generation based on project outputs.
Microsoft already has the ability to add project output for the current Setup Project. Adding XML output of these files outputs should be a comparably small task with a huge gain. With web projects, manually maintaining the file list is the largest complaint I get about WiX from the development team. I know automating this has issues with component rules, but there was talk a while ago that there is a solution that could be implemented using a component catalog database. This should also include the automatic Detected Dependencies.
2. Forms designer
The current WPF forms designer is a live dual view, form and XML. Add to the toolbox the Windows Installer form components and modify the XML generation engine.
3. Bootstrapper integration
This is already available via the GenerateBootstrapper MSBuild task. Add the interface as in a Setup Project or ClickOnce for configuration and Prerequisite selection. It would be a nice addition to both WiX and VS Setup projects if selections for the bootstrapper prerequisites, also sets the launch conditions on the MSI.
4. File System, Registry, File Types, User Interface Sequence, Custom Actions and Launch Conditions Editors
All these editors currently existing could be made to support WiX generation. This would be a huge step forward for WiX becoming mainstream. Since developers are not afraid to modify XML like WiX, it still comes down to the understanding of Windows Installer to do advanced things correctly, whether or not you have nice designers and authoring tools. However, this current set of editors has allowed many developers to author satisfactory installers without needing to know what is going on.
As a developer, I understand it is easy for someone of the outside to look in and say, "it should be quick and easy", but that is not often the reality. This is just my wish list. I do realise this is very early stages, and only more good will come of WiX with some full time developers on it. Exciting times ahead, other installation tool companies better watch out!
Simplifying Complication 
Good write up, I\’d like to address a few things.
VDPROJ Detected Dependencies: What have you found about this feature that you actually like? It\’s caused the teams I\’ve worked on way more problems then they were worth. We worked in an environment with ove 1000 merge modules and it would bring in dependencies in unpredictable and undesirable ways. In InstallShield it\’s a simple change `Properties and Dependencies` to `Properties Only` and life is bareable again.
GUIDS ( and Table Primary Keys ) After the whole `primary keys should not be arbitrarily changed` MSI Team Blog ( aka here is another component rule we never told you about ) ( aka "functions as coded" ) InstallShield has changed their authoring logic to be more like VDPROJ. If you ever notice, VDPROJ 1) hides components 2) doesn\’t really generate GUIDs. It actually uses a hashing alogorithm. In other words, follow the same directory path and file name and you\’ll get the same GUID generated. This seems to work well though so I\’m not sure it\’s a bad thing. Just something to be aware of.
I agree with your bootstrapper / launch conditions correlation pattern. So much, I designed this very thing 2 years ago! 🙂 I worked at a place where they used Wise SMS installer to write their bootstrappers and their MSI\’s in InstallShield. It was a nightmare because you had a developer doing the bootstrapper ( who knew Wise better ) and another developer doing the install ( who knew InstallShield better ) and they were communicating very poorly and choosing different implemntation methods for launch conditions. I redesigned everything to use fake MSI\’s as a bootstrapper that used the execute sequence to manage package caching and the UI sequence to manage UI and package installation. ( shell out of process to get around mutex problems. ) The real beauty was a system of merge modules: Find Modules to implement AppSearch patterns and Conditions moduiles to implement Launch Conditions. These were consumed by both the bootstrapper and the installers to make sure they behaved the same. There was a lot more to it then that but this is just a blog comment. 🙂
The Detected Dependencies feature I have found is great for simple installers. Often dependencies are just overlooked, and this feature makes you aware of all your dependencies. You are correct though, that a switch is required to be able to turn off this functionality. There are few things worse than a clever system assuming it always knows best, and then trying to work around it when it gets things wrong.