The validation assumes that the ALLUSERS property is not present or is set to 0. Even if you've set ALLUSERS=1 in your package, the user installing could set it to 0 on the msiexec command line, or a network administrator could deploy it in the per-user part of Group Policy. You should ideally try to make your package work for a per-user install, if you can (obviously if you're installing services this isn't going to work).
ICE43's complaint about the KeyPath not being a registry key relates, I think, to ensuring that if multiple users install a product per-user, that they will all get all the shortcuts. If you use a file as its KeyPath, and all the users install the product to the same location, the second time it's installed Windows Installer will see that the KeyPath is already installed, will skip installing the component, and will therefore not install the shortcut. To remove the error, make your non-advertised shortcuts children of a component which contains a registry key in HKCU (I'm not sure if HKMU is OK here). Sadly ICE43 is implemented in a DLL custom action so you can't (easily) crack it to look at the code (some of the ICEs are implemented in VBScript). Likewise ICE57 is warning you that some of the resources in a component are going to per-machine locations (it seems to assume that files go to per-machine locations unless you put them in a directory under one of the per-user system folder locations) while some are going to per-user locations. The documentation for ICE57 (http://msdn2.microsoft.com/en-gb/library/aa368994.aspx) says that 'mixing per-user and per-machine data in the same component could result in only partial installation of the component for some users in a multi-user environment.' Rob (or other MS employee), would it be possible to get whoever is currently responsible for the ICEs to explain why these are considered to be errors, with some scenarios? The ICE documentation is OK on what _causes_ a particular ICE message, but not very clear on the reasons _why_ such behaviour is considered incorrect. Right now it's impossible to make an informed decision. Regarding your PS: If software goes through a repair every time its shortcut is used, it might mean someone broke the component rules - typically, that the same file or registry key was installed by two different components, which disagree on what version of the file should be installed, or what the value of the key should be. Or, that one product's installer is an MSI, while another installs the same file directly (not using an MSI). You might have one application that registers an extension using Windows Installer, and another which steals that extension whenever it runs; when you launch the first application you'll get a Windows Installer repair dialog. My simplified (!) component rules are: - If you didn't write it, check the author's rules for installing it. If they suggest including it in your own MSI, get the right component GUIDs and composition of those components from whoever did (this might be a merge module); you might instead need to launch a separate installer. - If you can't get the right component GUIDs (no merge module, Fragment, or official installer), generate your own but make sure SharedDllRefCount is set to 'yes'. - If installing a resource to a shared directory, you must ensure that the component GUIDs and component contents are identical; - Change the component GUID if you have to add or remove a file, registry key or other resource, or if the new version of the file is no longer compatible with the old version (because Windows Installer will keep the newest file version); - Best practice is to have one file or other resource per component, unless specifically told otherwise (e.g. multi-file assemblies) - If you need to change the component GUID you must change the directory it installs to, to ensure that you don't end up with miscounted references (you can ignore this rule if this is a private component and you're uninstalling the previous version before installing the new one). It is OK to install the same component to different directories in different packages - Windows Installer tracks where each package put each component - but not to install the same resource to the same directory using different components in different packages. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of André Pönitz Sent: 20 December 2006 15:00 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Trouble with Shortcuts... Mike Dimmick wrote: > If you don't think you need install-on-demand, > repair-on-launch, or the ability for domain administrators to > advertise software through Group Policy, by all means use > non-advertised shortcuts. Which, unfortunately, does not seem to work with Wix v3 and validation. At leat not with a Shortcut element. That's where we started off IIRC. Regards, Andre' PS: I've already seen quite a few cases of software that try to go through repair on each and every attempt to use the shortcut. Adding to that the overhead of anything .msi related basically rules out the use of these shortcuts... ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
