On 5/1/10, wix-users-requ...@lists.sourceforge.net <
wix-users-requ...@lists.sourceforge.net> wrote:
>
> Send WiX-users mailing list submissions to
>wix-users@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>https://lists.sourceforge.net/lists/lis
I've got some custom actions that creates some sql server functions and
create an xml config file as one of the last things that happens in an
install.
If an error occurs in the custom action, I need the install to roll
back, basically to uninstall itself.
The sql server scripts are installed
In the log:
MSI (s) (9C:6C) [11:09:51:218]: Doing action: RemoveExistingProducts
MSI (s) (9C:6C) [11:09:51:218]: Note: 1: 2205 2: 3: ActionText
Action 11:09:51: RemoveExistingProducts. Removing applications
Action start 11:09:51: RemoveExistingProducts.
MSI (s) (9C:6C) [11:09:51:228]: Note: 1: 2
I've also had problems with embedded binary files (dynamic libraries,...)
Regards
Stephen
-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com]
Gesendet: Freitag, 30. April 2010 13:12
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Building Pat
yeah, findrelatedproducts is before removeexistingproducts.
In the log, what do you have related to RemoveExistingProducts? This is a
side issue, the main issue is that the property associated with the Upgrade
entry has no value which means it is not finding a match. Sometimes for this
I will cre
I was just using the example in the help file. I don't call
FindRelatedProducts directly, I'm assuming it gets called before the Upgrade
actions do. If not, how does one go about doing this?
-Original Message-
From: wallywojo [mailto:wallyw...@gmail.com]
Sent: Friday, April 30, 2010 11:
Hi Dan to point out here that might get you in the right direction. If you
are trying a launch condition based on a product lookup you cannot use
FindRelatedProducts since that happens after the LaunchConditions action.
--
View this message in context:
http://windows-installer-xml-wix-toolset.68
I looked at the thread in the archive, but it appears that this person
didn't resolve his issue (or at least didn't post when he did). Here's what
I've got:
..
The InstallExecuteSequence if after the
This seems like a good and sound plan. Will 3.5 be moved over to codeplex as
well (or updated so the source build from a version control repository)?
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Wednesday, April 28, 2010 11:07 PM
To: General discussion for
may not need anything additional, I am pretty sure that a Full MSI validation
would report this. Have you tried to validate the built MSI?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Could-WiX-warn-about-this-tp4986969p4986987.html
Sent from the
I've just made a mistake like the following simplified example
This is a 64 bit installer, which needs to install both the 32 and 64
bit versions of a DLL in the respective system folders.
This all works fine until I come to do an adminis
thanks Jim, yeah missed a small step with my custom dialogs.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/LGHT0048-The-document-element-name-Wix-is-invalid-tp4986792p4986860.html
Sent from the wix-users mailing list archive at Nabble.com.
--
It looks like you are trying to link (light) WiX source files.
Shouldn't you be using 'candle' to compile them first
Jim Williams
On Apr 30, 2010, at 10:18 AM, wallywojo wrote:
>
> I searched and found a few matches with no replies. Can anyone
> assist when
> building with this
>
> E:\User
I searched and found a few matches with no replies. Can anyone assist when
building with this
E:\Users\\Documents\WiX Projects\DSMail\DSMail>light -o "Mail
Test.msi
" -ext WixUIExtension Product.wixobj SecuritySettings.wxs
EncryptionSettings.wxs
DLHServerSettings.wxs DigitalSafeConfigSettings.wx
I know of no scenario where you'd want to do that. That's on reason why it
isn't made easy.
On Fri, Apr 30, 2010 at 9:12 AM, Castro, Edwin G. (Hillsboro) <
edwin.cas...@fiserv.com> wrote:
> If you absolutely need to change the Product UpgradeCode on every build (Is
> this a good idea?), then you
If you absolutely need to change the Product UpgradeCode on every build (Is
this a good idea?), then you'll need to extend your build process to do it
yourself. XML is relatively easy to change, especially in PowerShell. Executing
something like the following could help:
powershell -command "$w
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Good luck with changing the UpgradeCode every time you build. You may as
well just remove it instead as it's about as useful as a chocolate
fireguard with that requirement.
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.ie
Hi
Is there a way that a new GUID can be added to specific location within WiX
at compile time?
I have created a common WiX file, and I want to add a new GUID upon each run
to:
* Product Id
* Product UpgradeCode
* Component Guid
I read in one blob
http://johnmcfadyen.spaces.live.com/?_c11_Blog
It is: InstallShield works in the same configuration.
-Original Message-
From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com]
Sent: Friday, April 30, 2010 00:36
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] TFS 2010, Network Service and ICE valida
Yes because using Custom Actions to circumvent Windows Installer
functions never caused anyone any problems.
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/UAC-issue-
td4947851.html
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 94
There is a way; use a CA which checks what OS you're running on (x86 or x64)
and then use the registry redirection flags or functions to inform the
registry redirector to use the correct registry.
Note that these functions only work on x64 OSses (they do work in x86
exeutables on x64 OS).
Not su
How to display UI dialog from C++ custom action? I found function
MsiPreviewDialog(). It need a handle to the preview. I Found
MsiEnableUIPreview() function, whitch need a handle to database. I try to
get database handle from MsiGetActiveDatabase() and MsiOpenDatabase() and it
was allways 0.
P.S.
If you drop the path and extension, candle.exe and light.exe will both look
in the same directory as they are in. Thus, ' -ext WixUtilExtension ' should
be sufficient.
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Tuesday, April 06, 2010 7:50 AM
To: General
Did you get any resolution on this?
Many of the problems you are describing look to me like the kinds of things
that happen when the component rules are violated. No amount of
hacks/workarounds cleans up the mess in that case.
Some questions: which build of the wix toolset are you using? How are
We ended up just (writing) using a deferred CA from http://msiext.codeplex.com
with a condition.
Uninstalling
Uninstalling
dB. @ dblock.org
Moscow|Geneva|Seattle|New York
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Friday, April 30, 2010 5:57 AM
To: 'General discuss
MSI runs external (exe) custom actions in the temporary folder. It may be
possible to change the TEMP environment variable, but it must be changed
before the MSI service starts and it must be changed for the SYSTEM user,
and McAfee in that circumstance will probably prevent files in that new
folder
Usually this is caused by A/V software running on your build machine.
-Original Message-
From: Kyle Huey [mailto:ksh...@ufl.edu]
Sent: Saturday, April 03, 2010 12:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Building Patches With Pyro
Hello All,
I
Example code that isn't working please? How many rows are in your Signature
table?
There is no way to control the order that the rows in the Signature table are
evaluated, but for each row there, the order of the other tables should be as
documented.
-Original Message-
From: Szentpali
An MSP can be marked as "uninstallable" which would mean the only way to
remove the patch is to remove the product it modifies.
-Original Message-
From: Markus Karg [mailto:k...@quipsy.de]
Sent: Thursday, April 01, 2010 3:20 AM
To: General discussion for Windows Installer XML toolset.
Sub
Build an x64 package to write to x64 areas of the registry. You can't do
it in an x86 package. Nothing to do with WiX, Windows Installer
limitation.
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate
I believe you shouldn't include the quote characters in your PATH statement.
-Original Message-
From: Markus Karg [mailto:k...@quipsy.de]
Sent: Thursday, April 01, 2010 12:45 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WiX 3.5: Error in HEAT
WiX
It is the correct path, as long as your executable is running as 32bit
on a 64bit system. Registry redirection is at play
(http://msdn.microsoft.com/en-us/library/aa384232%28VS.85%29.aspx)
On Fri, Apr 30, 2010 at 12:39 PM, Yu, Brian wrote:
> Hi there
>
>
>
> I found by testing that in 64 bit XP,
Well, it is not a bug, technically. It's a security issue. The problem is
that there is no documentation. I'd think someone in here might know how the
wix build tasks interact with msiexec and what security issues may be
involved...
-Original Message-
From: Sascha Beaumont [mailto:sa
I'm assuming Program1 and Program2 have different ProductCode values. It
would appear to me that the shared shortcut should be left behind as you
expect given the code you present. RemoveFolder will not remove any
non-empty folders, so that isn't what is deleting the shortcut.
Generate a verbose l
Hi there
I found by testing that in 64 bit XP, the registry path is somehow
different
It should be hklm/SOFTWARE but now becomes hklm/SOFTWARE/wow6432
How do I get WIX to selectively install into the right paths depending
on whether it's XP or Win7
Brian
_
Unless the transient flag is set on a component, conditions for that
component are only evaluated upon installation of that component.
I think a little illustration here of what happens during installs,
upgrades, and removals will help you understand.
Initial installation: component with GUID in
Do not ever create custom actions and call regsvr32.exe from MSI/WiX. In WiX
2.0, use the SelfRegCost attribute of the File element to cause MSI to
perform the actions of regsvr32.exe on your behalf in a way that works with
repairs, upgrades, patches, as well as installs and uninstalls.
Of course,
this C++ custom action can check drive type.
use a C++ custom action and display a error message if drive is not valid.
//char AppPath[_MAX_PATH];
char appName[_MAX_PATH];
char appDir[_MAX_PATH];
char appDrive[_MAX_PATH];
_splitpath_s( cP
http://www.freidesignberlin.de/home.php
_
South Cinema This Decade
http://entertainment.in.msn.com/southcinemathisdecade/
--
Anybody???
-
Andy
MSI Developer
Schneider Electric
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Avoid-install-on-removable-drives-tp711163p4984485.html
Sent from the wix-users mailing list archive at Nabble.com.
41 matches
Mail list logo
