Re: [WiX-users] yep - back to being 100% frustrated

Hi I just wanted to add that some of us had working installers before. In our case this goes back to a fossil InstallShield v3 script based solution. The only reason we're really forced to replace it, is because it contains 16bit bootstrapper code, can you belive it ;-) All the real deployment

Re: [WiX-users] yep - back to being 100% frustrated

Hi all > If you reverse it, and do the install up front [...] I agree that things like KnownFolders and related security implications should be considered early in the development process. But this should be a high-level architectural topic, well above the trenches of writing an actual installe

Re: [WiX-users] yep - back to being 100% frustrated

Hi all > If you reverse it, and do the install up front [...] I agree that things like KnownFolders and related security implications should be considered early in the development process. But this should be a high-level architectural topic, well above the trenches of writing an actual install

Re: [WiX-users] yep - back to being 100% frustrated

Hi Richard > Creating plain shortcuts is rather straightforward It's not the shortcut @Target but the @Name I wanted to vary. >Shortcut [..] ICE There seems NOT to be any other solution than to use a dummy current user(!) registry entry according to various blog entries by the "gurus". I just

Re: [WiX-users] yep - back to being 100% frustrated

oftware!) Cheers. _Mark -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Richard Gesendet: Montag, 12. Mai 2008 21:10 An: WiX Users Betreff: Re: [WiX-users] yep - back to being 100% frustrated In article <[EMAIL PROTECTED]>, "Ma

Re: [WiX-users] yep - back to being 100% frustrated

Hi Chris I can only second your opinion. It's almost unbelievable, how difficult even the most common, primitive task is. One has this long-honed professional developer instinct that constantly tells you "there must be an easier way, I just have to find it". Believe me: in case of MSI there is

Re: [WiX-users] How do I preserve a configuration file on a majorupgrade?

> I did it with a custom action, but that's admitting failure :) That's exactly what I'm also trying to achieve. Can't believe one needs a custom action for that, but it seems that way! Whatever I tried so far, MSI never always does the right thing on install/repair/major upgrade/uninstall.

Re: [WiX-users] File overwriting rules

richt- Von: Wheeler, Blaine (DSHS/DCS) [mailto:[EMAIL PROTECTED] Gesendet: Samstag, 29. März 2008 00:08 An: Markus Kuehni Betreff: RE: [WiX-users] File overwriting rules Check the Installer rules for non-versioned files http://msdn2.microsoft.com/en-us/library/aa368599(VS.85).aspx and http://

[WiX-users] File overwriting rules

Hi (I haven't received any replies to my last post, so I'm trying again - simpler this time) I have a dilemma concering the overwriting of a (unversioned) file: On Install (including upgrades), it must be overwritten, even if older by date. On Repair, it must never be overwritten. Is this

Re: [WiX-users] AppSearch during Maintenance Installation

Hi > Bob Arnson wrote > >AppSearch runs during maintenance mode unless you've added a condition to prevent it. >Check a verbose log to see what's happening. Ok, after I found a way to enable logging when coming from "Add/Remove Programs" (see at the end), I was able to see that indeed AppSea

[WiX-users] AppSearch during Maintenance Installation

Hi How can I schedule actions during a Maintenance Installation? Specifically I need to perform AppSearch in order to locate third party paths and registry settings. Background: our application provides interfaces to several third party software solutions. At the time of install, some may not

[WiX-users] RemoveExistingProducts placement

Hi On a related note to my previous post (rules on overwriting files), I wonder, what exactly the effect of placing the is. I'm doing major upgrades only. No shared components. In order to make the upgrade as efficient as possible, I currently use or in order to make it into one trans

[WiX-users] File overwriting rules

Hi I'm currently strugling to understand file overwriting rules in different scenarios. (I know this is somewhat off WiX topic and more general MSI knowledge - but then what isn't? :) I understand the REINSTALLMODE property controls when components do overwrite one another or not. http://msd

[WiX-users] Shortcut/@Name does not expand properties?

Hi It seems that a shortcut name cannot be varied at install time. Is that correct? Thanx for all help, Mark - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://cl

Re: [WiX-users] Always change the product code?

, Mark _ Von: Alexander Shevchuk [mailto:[EMAIL PROTECTED] Gesendet: Sonntag, 9. März 2008 19:41 An: Markus Kuehni; wix-users@lists.sourceforge.net Betreff: RE: [WiX-users] Always change the product code? Hi Mark, Major upgrade (http://msdn2.microsoft.com/en-us/library/aa369786(VS

[WiX-users] Always change the product code?

Hi After having read about all the gotchas of minor upgrades, including the necessity for msiexec command-line args, I think it's best (in our case) to always change the product code and be sure to always get a clean install. I expect it results in more file deleting/copying activity than woul

Re: [WiX-users] Localization with WiX3

>Bob Arnson wrote: > Because, as you note, they don't work without modification. Ok, but then you should probably remove WixUI_de-de.wxl as well. It was very confusing for me to have German *half* working and French *not at all*. Whatever, the thread will hopefully clarify this for others. A

Re: [WiX-users] ServiceInstall on EXE that is already installed?

Thank you both. So there is no way to include a "dummy file" that is never actually installed or uninstalled? _Mark -Ursprüngliche Nachricht- Von: Michal Peled [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 14. Februar 2008 18:31 An: Markus Kuehni; wix-users@lists.sourc

[WiX-users] Localization with WiX3

Hi Because it was not obvious to me and because I didn't find a solution using Google, I'll post my findings here. If you want to localize your UI with WiX version 3 and need more than US-English, German, Spanish or Dutch you're stuck. Strangely the localizations files from the version 2 are

[WiX-users] ServiceInstall on EXE that is already installed?

Hi is it possible to include a ServiceInstall that refers to an .exe file that is not part of the installation? Could I somehow use a "virtual" File element (which defines the KeyPath needed to define the service executable) that refers to the install location of the already existing file and

[WiX-users] ServiceInstall on EXE that is already installed?

Hi is it possible to include a ServiceInstall that refers to an .exe file that is not part of the installation? Could I somehow use a "virtual" File element (which defines the KeyPath needed to define the service executable) that refers to the install location of the foreign/already existing f