And the set of before the CoPr are not random values either, and you
will need to ensure that they don't conflict with the GUID specifications
either.
Blair
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Monday, May 09, 2011 10:11 PM
To: 'General discussion for Windows
Each byte in a GUID is NOT UNIQUE: there are guid versions, etc. of which
Office and the COM infrastructure make use of certain types of GUID that
most applications don't use to help avoid collisions.
Unless you are following the spec of how to build a GUID, I wouldn't
manufacture them that way.
Don't set REPAIR when applying the patch?
The default action when a patch is applied is to apply as few features as
possible based on the changed components. The only way a previously
not-installed feature is automatically added is when it and all of its
components are added by the patch.
A verbo
The WIXPDB files only contain the files if they were built using "bound" or
"binary" WIXOUT/WIXLIB files (which you can get using light's (or lit's) -bf
command-line argument). Files that light incorporates directly into an MSI
are never "bound" to the WIXPDB.
Alternately you can write a BinderFil
Look at ComponentSearch.
Blair
-Original Message-
From: Aaron DeMarre [mailto:adema...@gmail.com]
Sent: Friday, May 06, 2011 1:38 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Property Behavior in Repair vs. Upgrade
I am wondering if there is a way to get my major upgrade
Not certain, but try saving the Path add string to registry and read it back in
on Uninstall.
Also if someone adds a Feature through maintenance mode, you can append to the
path string. Your biggest issue would be if someone selectively removes a
feature.
Michael
-Original Message
Michael,
Any tips on how to implement compensating action on uninstall?
Should I preserve the property in xml file or registry?
Any other implementation?
Martin
-Original Message-
From: Martin Kulov [mailto:mar...@kulov.net]
Sent: Tuesday, May 10, 2011 3:32 AM
To: wix-users@lists.sourc
Hello James,
Is there any reason why you do not use the Package Platform=x64 or
package Platform=x86? It is my understanding that you would not need to
explicitly reference ProgramFiles64Folder if this is set to x64.
If you want to be able to upgrade between 64-bit and 32-bit versions of
your pr
Hi Michael,
That was something I was playing with. However your solution just nailed it!
One comment for the history - one should use public property like PATHADD
instead of PathAdd to make sure property is transferred between user and
service mode.
Thanks a lot!
Martin
> From: mosm...
Hi,
I'm following http://wix.sourceforge.net/manual-wix3/patch_building.htm
to create a patch, but while testing the patch I discovered, that it
didn't remember the feature settings from the original installation. I
found that there is a way via MigrateFeatures on UpgradeVersion, but
this seems
Are you using the same UpgradeCode?
Blair
-Original Message-
From: James Robertson [mailto:ja...@osodata.com]
Sent: Friday, May 06, 2011 4:58 AM
To: WiX
Subject: [WiX-users] 32-Bit < > 64-Bit
Hi,
I have an existing installer for a 32-bit application that has been working
fine for the l
Create a Feature Request on SF?
Blair
-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: Thursday, May 05, 2011 6:23 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Creatin User Group and add current user int
Hi Martin
You could build up a single property with the PATH entry you wish to add using
a series of Type 51 Custom Actions. Each would add the path option for a
feature and be conditioned by the feature state. You then have a single
component (linked to you Register Environment Variables fe
Hi all,
I would like to set environment variable PATH based on other features that
user has selected to install. PATH should set only the paths for selected
features. Additionally user must turn on and off PATH registration by
choosing to install feature called "Register Environment Variables".
Hello there.
I've been struggling around this subject for some time now, and I'm
wondering
about the best approach to follow on achieving such objective.
Right now, what I am thinking on is to mock all the installer by
customizing
the entire dialog set and placing all the dialogs one behind the ot
Hi Aaron-
I'd really have to have a long talk with you to fully understand what you are
doing but my hunch is that your custom actions and registry searches are over
complicating the problem. You might want to look into things such as
MsiEnumRelatedProducts to let you make the jump from Up
(Sorry, not connected to the internet right now so can't add this to the
bug)
WiX Team: My company will pay for the certificate. Let me know where to
send the check.
John
Wintellect
http://www.wintellect.com
+1-877-968-5528
On 4/25/11 9:23 PM, "Blair" wrote:
>Please file a feature request so
Having just done this, it will work. Except you have to write the command
line parsing yourself. :) In your Run method, grab the CommandLine from
the Engine and it will have all the options *not* related to Burn.
John
Wintellect
http://www.wintellect.com
+1-877-968-5528
On 4/19/11 5:18 PM, "Sta
I appreciate that input tremendously! I had figured that the replies here
would be something to that effect (thanks to David also). Really, all that
we need is a deterministic way to generated GUIDs (to GREATLY simplify our
WiX authoring and maintaining), and we had thought that something like this
IMO, I don't ever do this. I really don't care who does and what reasons they
come up for doing it, I don't and will not ever do it. I also generate
ProductCodes at build time to support major upgrades. I've also generated
multiple instance installers where I generate new guids for each of t
Why not just write the information you require in the registry and store it
in a public property in each MSI.
That way you can generate your product code as normal and run no risks of
current or future problems with not following the guidelines for GUID
generation.
You can even make it more human
We are considering defining our product codes for our different instances
with a bit more structure than the random GUID generation that is usually
recommended. We are considering this because we have to define a large
number of product code GUIDs for each product AND change them every time we
do a
We are considering defining our product codes for our different instances
with a bit more structure than the random GUID generation that is usually
recommended. We are considering this because we have to define a large
number of product code GUIDs for each product AND change them every time we
do a
Not sure how far back this goes but as of one of the wix builds in April
2011, there is an attribute called 'MultiInstance' that can be put on
components to make the component have a different guid in each transform. So
it would look something like this:
That fixed our problems with registries an
Yes. Come to think of it, the shortcut name is the name of the lnk file and
when you change the file name or location you must change the guid anyway.
Sorry, I should have remembered that :)
-Original Message-
From: Michael Tissington [mailto:michael_tissing...@ciqual.com]
Sent: 09 May 2
Thanks for the idea of that - however that introduces a bunch of other
problems.
Will it work if I simply change the component guid for the shortcuts?
-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Sent: 09 May 2011 14:07
To: General discussion for Windows Instal
Move RemoveExistingProducts to before InstallInitialize. When it's before
InstallFinalize, it won't remove everything first - it installs the new
product on top then removes anything that wasn't in the new installer.
-Original Message-
From: Michael Tissington [mailto:michael_tissing...@c
I'm having a problem when performing an upgrade and the shortcut name has
changed.
I have scheduled RemoveExistingProducts to before InstallFinalize.
In the upgrade install I have changed the names of the shortcuts.
The problem is when I do the upgrade the old shortcuts are not removed,
File data components automatically installed/related with their product so
unique guids are not needed. However, non file data components ( such as
registry keys ) behave a little different and need to have unique components
with conditions to associate with the various instances being install
What about component guids? I have tried to understand the component rules,
and I thought that each component (that is
each target file if one does component per file) should have it's own guid.
I thought that if two target files used the same guid,
one would be left behind after trying to install
Hi all,
I'm following the example
http://wix.sourceforge.net/manual-wix3/wix_patching.htm to create a patch.
Everything works fine on test binaries built on my local computer.
However, I got "error PYRO0001: Could not find file" when I changed to use
released msi file built by team's build machin
31 matches
Mail list logo
