> Would you mind to share that? Don't want to mock you (if it was your fault), > but it might be helpful for the archives and the next one that searches for > similar terms.. >
Oh, no, I don't mind. As I said before, I never thought WiX was broken, and I fully admit my ignorance since I'm new to WiX and MSI. Just because I'm a seasoned software engineer doesn't imply that a new tool set won't cause me to publicly humiliate myself from time to time. *grin* The Short Answer: I learned as a MSI/WiX noob is the power of disassembling the MSI files when trying to replicate and improve an existing installer produced with InstallShield. It's useful to see what MSI is being told to do. That may have saved a lot of heartburn had I done that earlier in the process. The problem ultimately was an obscure bug in the application (surprise, surprise). It was the way I was using WiX (adhering to standard good software engineering practices) that revealed the bug. The Long Answer: For the record, here are the gory details of the process I went through, in case somebody in the future has similar troubles. This is a very complicated piece of software with scores of assemblies (including a number of wrappers around unmanaged plain and COM DLLs), so the likelihood of messing something up shouldn't be discounted. Heat did it a great job doing the heavy lifting, getting me 80% of the way there. I ended up having to retouch the XML on each of the entries, and I broke the massive output into manageable fragments. The initial symptoms were: 1) The application was crashing very, very early in the initialization stage. 2) Installing debug-enabled binaries produced only one diagnostic message, essentially "I'm starting". "Obvious" Conclusion: Something different between the two MSIs was triggering the crash. I've seen goofy stuff like that before when Windows found something basic but critical out of place. Based on that past experience, I started going through a process of elimination to determine what was out of place and was causing the crash. There were some great hints for how to diagnose the problem, many of which I had already done. For example, Christopher suggested maybe .NET wasn't installed. Andreas suggested to check that all of the files were actually installed, and in the correct locations. Those were the first things I checked. After diffing the directories and files, I diffed the registry changes. The main thing that stood out was the private assemblies section that InstallShield produced, but not WiX. This was my wrong turn. I wrestled with what those registries meant for a while, and when stumped posted my question yesterday. What got me back on track this morning was when I saw that I could just copy the installed directories to a clean machine. I decided that the registry hunt was the wrong path. Bob's suggestion to use dark to decompile the two MSIs was timely. Dark's output of the two MSIs allowed me to see the intimate details of the InstallShield advertised shortcuts. In the Arguments attribute, I used the [foo] syntax to build an absolute path to a configuration file, while InstallShield provided a hard-coded relative path. Specifically, in one fragment I declare the directory structure, which includes a subdirectory with an Id of the form dirFooConfigs. In another fragment I declare shortcuts. In the <Shortcut> tag I included arguments of the form Arguments=""[dirFooConfigs]$(var.fooConfigFile)"" to produce a full path to the file surrounded by quotes due to the spaces in directory names. The application, it turns out, has a fatal bug that barfs horribly on the absolute path that I told WiX to build. It is well formed and correct. However, in the thousands of man-hours developing the software, nobody ever tried feeding the application a reference to the config file in that exact way... that never happens, right? So, I was right that /WiX itself was never the problem/. I did run down the wrong path based on diffing the registry, combined with my ignorance of what I was seeing in the registry produced by InstallShield. Again, in summary, the main lesson I learned as a MSI/WiX noob is the power of disassembling the MSI files to look at things as MSI sees them. I hope that somebody finds that useful in the future. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
