> -----Original Message----- > From: Peter Stein [mailto:pst...@instec-corp.com] > Sent: Thursday, July 28, 2011 4:14 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] RemoveExistingProducts doesn't work in 3.5 > > Not sure why this is so difficult to understand. The installer has components > that are safe to install in some environments/contexts but not in others. Yes, > the installer could be decomposed into multiple installers each of which only > installs a single feature but that's just plain goofy as the users have the > wherewithal to know which feature is appropriate for their install. As a > safety > precaution we simply don't want unneeded executables installed when they > don't need to be because the individuals using the software aren't > necessarily the same ones who installed it. You're misinterpreting something > fairly straightforward because you are looking at it through the filter of > WiX. >
There is no WiX filter here. I don't think we were discussing having multiple packages at all... We were talking about feature/component composition within a single package. This is strictly a Windows Installer concept that WiX (not the same thing) allows you to define using a XML syntax. WiX doesn't set the rules here. Windows Installer sets the rules. Now, if you are trying to say that I have a Windows Installer filter on then, yes, you are correct and I would argue that's appropriate since you are trying to author a Windows Installer package! To see what the Windows Installer SDK (not WiX) has to say about feature/component composition see http://msdn.microsoft.com/en-us/library/aa370561.aspx > And no, I'm not using a directory path too early. NO, NO, NO! > In fact the problem is the exact opposite I can't use it early enough. I > clearly > said "after CostFinalize" because only then is the DM initialized. I want to > move the whole dialog chain towards the front of the InstallUISequence as > far as it can go, but there are dependencies on the standard UI actions. > You would not be getting DM uninitialized errors if you were not trying to use the directory paths before they are available. Again, this is how Windows Installer works. WiX does not have anything to do with this. > By now it should be clear what I'm trying to do. A feature dialog is being > executed *after* CostFinalize and therefore *before* ExecuteAction. This > dialog determines the set of features to be installed. But the actual > installation ignores this information. I know why, because it needs to be > available *before* CostFinalize (see description). But in order to make it > available *before* the dialog chain would need to be moved up in the > sequence, something that can't happen because of the DM dependency > (and possibly others). I think this pretty clearly sums it up. > Sounds like you are trying to setup an execution sequence that doesn't work. See http://msdn.microsoft.com/en-us/library/aa372039.aspx for the Windows Installer SDK's (not WiX) suggestion for a base InstallUISequence. The table in that page tells me that you are trying to author something that won't work. > I'm not trying to sabotage anything, just trying to use a tool to do something > *very* reasonable. WiX doesn't seem to have the correct coupling between > the UI and control logic. Or the user documentation that explains how to > achieve that. Or both. Even a new CS grad knows that you don't start > processing inputs before the connected UI has even served them up! > Actually, that previous paragraph is the exact definition of sabotage. Windows Installer (not WiX) says that directory paths are not available until after CostFinalize (http://msdn.microsoft.com/en-us/library/aa368048.aspx). Windows Installer (not WiX) suggests that all of your UI dialogs execute *after* CostFinalize. You (not WiX) are trying to change the InstallUISequence to something that makes more sense to you but does not take into consideration how the Windows Installer engine works (again, not WiX). Your definition of reasonable doesn't matter if it contradicts the framework you are trying to use, for better or for worse. Windows Installer (not WiX) works a particular way and I have found that it works really well if you don't do anything to upset it. I would say that you are doing a lot to upset it and Windows Installer (not WiX) is complaining heavily. WiX (Windows Installer XML) is a XML syntax for defining Windows Installer packages that are consumed by the Windows Installer engine. WiX does not have the ability to change Windows Installer no more than InstallShield can. There are some setup authoring tools that do not use Windows Installer at all! NSIS is an example that comes to mind immediately. If you are going to use WiX as your setup authoring tool then you must follow the rules set by Windows Installer. Edwin G. Castro Software Developer - Staff Digital Channels Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
