Read the descriptions of the following ICEs: ICE18, ICE38, ICE43, ICE57*, ICE64, & ICE91. (I'm sure I'm missing one or more additional pertinent ones somewhere) *ICE57 doesn't check the value of ALLUSERS because that property can be overridden during an installation, so if it thinks the referenced location *might* be user-profile, it is considered user-profile.
In general, any installation that puts things in both per-machine and per-profile locations will eventually (depending on circumstances, especially with roaming profiles and with multiple users on the same box) "cause problems", either with reinstallation or with orphaning data, or both. It is best to make your installations pure-perMachine or pure-perUser and never mix them, and treat data generated during the running of the application as user data, not program data (even if it isn't formatted for the user's direct use nor placed in their "Documents" (or "My Documents") folder). Since the directory property values associated with the Start menu vary (based on ALLUSERS) and can be profile data (but don't have to be) the ICE tests kick in and impose requirements that, for pure perMachine installations, often seem completely brain-dead. Since the requirement that the ICE test is intending to protect you from may not apply to your installation, you may not want the requirement to add useless additional registry keys in places you prohibit yourself from placing resources. WiX supplying those additional resources on your behalf without you knowing or explicitly consenting to would not be considered a good thing by many who depend on authoring and knowing exactly what is in their packages, and who are prepared to deal with ignoring certain ICE reports they consider irrelevant to their package. "... roaming profiles seemed like such a good idea at the time ..." wistfully heard around SetupLand. The rational for using registry instead of file location for the Start menu is this: If the keypath of the component is user "A"s Start menu, then user "B" will never have a shortcut (since it points to a particular non-profile-generic location. If, on the other hand, the keypath is a HKCU registry key/value, then when user "B" touches the installation, they will get the shortcut added because its component will be seen as "missing" invoking a repair. However, you shouldn't do that to your users since you should be putting your shortcuts in "All Users" if you install perMachine, and B will never be able to access the program if it was installed perUser in A's profile, negating the problem in the first place. Thus, the logic of the ICE is flawed, in my opinion, if you employ reasonable rules, and may possibly be ignored. However, if you are seeking approval for Windows Logo, you may not be able to ignore these ICEs (I don't really know, I have never submitted an application for Logo), thus "your mileage may vary". In C++, if I forget to call delete in a tight loop that calls new and leak memory as a result, I don't want the compiler calling delete for me, since that tight loop may actually be storing those pointers somewhere (it may not be a memory leak after all). Same principles apply here. Just as C++ gives you the Windows Platform with only some protection, WiX gives you Windows Installer with only some protection. It hands you the loaded gun. It doesn't force the direction in which you point it. That direction is up to you. Just as you have to understand the technology you program to make effective and secure use of it, you have to understand the technology you author to make effective and secure use of it. Just because many of the other toolsets for Windows Installer try to hide the technology (and usually do unsafe or unreliable things as a result) from the developer doesn't mean that WiX should. Back in the 90s we used to say that VB protected you from the platform and C++ allowed you to hang yourself with it. Both VB and C++ have progressed since then, but the basic idea is still the same: if you want/need the power of the platform, you go with the tool that gives you that power, but with that comes the responsibility to understand the platform. Tools that don't give you the full power may never be able to address all your needs (or may become so complex in attempting to do so in a safe fashion that you get caught in the seams) that they become too expensive one way or another for your needs. Yes, we recognize that Windows Installer is a technology area that hasn't yet received enough good documentation and explanation. Some of us are working on that (slowly, as we can). Please keep these questions coming. They help us remember what we didn't understand when we were first confronted with this space, and that is invaluable in trying to get us to improve the way we disseminate the "tribal knowledge" associated with application deployment and servicing on Windows Platforms. -----Original Message----- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Sunday, November 01, 2009 8:48 AM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] (no subject) The WiX manual contains the following: "The first is a RemoveFolder element, which ensures the ApplicationProgramsFolder is correctly removed from the Start Menu when the user uninstalls the application. The second creates a registry entry on install that indicates the application is installed." I have two question about this: (1) Why do I have to care about removing the start menu folder? I know, that this is some issue with the Windows Installer Server (even I actually do not understand the issue). But since it is a *general* issue that *any* Start Menu folder will suffer from, why does WiX not solve the problem on it's own but instead forces the .wsi author to remind this in each and every .wsi file? (2) If I (as an MSI beginner) understood correctly, the idea of the key file is to have one unique "thing" that Windows Installer will check to see if the component is installed currently. What I do not understand here is, why the the abovementioned example is using an artifical (not further needed) registry key to remind itself about the need to remove the Start Menu folder? I mean, why isn't it possible to reference the start menu folder itself, or at least, why not referencing the installation's main file instead of introducing an artificial registry entry? Sorry for my silly questions, but I want to really understand this, and MSDN does not really say why but only what. Thanks Markus ---------------------------------------------------------------------------- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
