Did you get any resolution on this? Many of the problems you are describing look to me like the kinds of things that happen when the component rules are violated. No amount of hacks/workarounds cleans up the mess in that case.
Some questions: which build of the wix toolset are you using? How are you generating your component guids? Are you generating your installer code as part of your build, and if so, how? Principally what has to happen (for the component rules) is that each file should generally be in its own component, that component's GUID should be stable (only change if the file either moves or is renamed) from build to build, and the FileVersion of the files should also change build-to-build (.NET uses AssemblyVersion, not FileVersion, for strong-name matching, so that shouldn't be hard to do). For GUID generation, I recommend '*' since the code automatically follows the above rules for stability relative to filename and directory, but that requires WiX 3.x. Also, don't change your directory layouts from build to build without thinking about them a lot first. For 32-bit/64-bit: create two MSIs and only install the MSI corresponding to each platform. An x64 MSI can place anything exactly where you want it on any x64 platform, and an x86 MSI will place things exactly where 32-bit code can/will find it. -----Original Message----- From: Thomas C. Corelis [mailto:t...@xlotus.net] Sent: Monday, April 05, 2010 2:33 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] On managing dependency hell with WiX and C# Hi everyone, I posted the following question originally at Stack Overflow (here: http://tinyurl.com/yb6n9qb) and it was suggested I bring it up here: "We are on the eve of product launch, and at the last minute I am being bombarded with crash reports that appear to be related to our installer, which is a WiX3 project with separate outputs for x86 and x64 builds. These have been an ongoing problem that I always thought were fixed, only to find out that they were still lurking. "The product itself is a collection of binaries that communicate with each other via .Net remoting, including a Windows Service and a small COM component that is loaded as an addon in another app. The service runs as SYSTEM, the COM piece runs in a low-rights context, while the other pieces run in normal user contexts. Other pieces include an third-party COM object library DLL and a shared DLL with the .net Remoting interfaces. "I've observed flat-out weird behavior with MSI, particularly on version upgrades. Between MS' anal strong-name implementation (specifically, the exact version check before loading a given assembly), a documented WiX/MSI bug that sees critical files erased on upgrades (essentially, if a file in the upgrade MSI has the same version number as the existing install, that file is deleted), and having to work around Wow64 virtualization (x86 MSI can only write to registry/HD locations via Wow64, yet x64 MSIs cannot run on x86 computers...), I am about ready to trash the whole thing and port it over to a different install system (NSIS maybe?). "What I am looking for on tips + tricks, techniques, or suggestions on how to properly do things so that I am not fighting with Windows Installer's twisted sense of logic. I am tired of fighting with WiX/MSI/Windows Installer. All it needs to do is place files and registry keys where I tell it to, upgrade them when appropriate, and don't delete anything until the user uninstalls, preferably without hacks. Instead, dependencies are deleted willy-nilly, much code is duplicated, and my app is throwing up a whole bunch of weird, uncatchable 'assembly not found' exceptions. "I am particularly interested in 'best practices' and examples regarding shared and dependency DLLs, and any tips on making sure if a file needs to go to GAC, that it actually goes to the GAC and stays there until it is appropriate to remove it." I have specific examples I can provide if needed, but to be honest the code on my end has been rewritten so many times that I am not sure how useful such things are. I would love to re-simplify the master wxs file, as right now it is quite large and has a fair amount of duplication due to the need for separate x86 and x86/x64 support. I've tried spinning out various pieces into merge modules, placing required files in GAC, placing required in the install folders... and every time, I run in to problems with the users' upgrade process. Thanks! Tom ---------------------------------------------------------------------------- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users