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

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

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 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] yep - back to being 100% frustrated

% frustrated In article [EMAIL PROTECTED], Markus Kuehni [EMAIL PROTECTED] writes: 1. learn how to write custom actions and use them liberally Disagree 2. learn how to write custom dialogs and use them liberally Use custom dialogs only when needed; most projects don't need them. 3

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

- 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://msdn2

[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 AppSearch

[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 RemoveExistingProducts is. I'm doing major upgrades only. No shared components. In order to make the upgrade as efficient as possible, I currently use

[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

[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.

[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

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

: 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.85).aspx) is the easiest

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.

[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

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.sourceforge.net