try:
http://robmensching.com/blog/posts/2010/5/2/The-WiX-toolsets-Remember-Property-pattern
On Tue, Aug 3, 2010 at 6:17 PM, saikodi saik...@hotmail.com wrote:
Hello All,
This is my first post here. I am not sure if there are any guidelines here.
I have a custom application for which I
Thanks Rob!
After reading the link you gave me, I figured out how to remember
properties. Here is my next problem:
1. Lets assume during install time, the msi was called with 2 command line
params (name=value).
2. I stored each of these parameters in one registry value each (so stored 2
params
Hey Rob,
I tried saving the properties in the registry but I dont think its working.
Does it really create the registry values in the registry? Can I look at
them post installation? In my scenario, the registry values are not being
created.
Also, I attempted a repair with l*v option for logging
Use the RegistrySearch described in the link to get the value from the
registry. You don't need to change anything to make it work when you uninstall
from the control panel.
Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
Hi,
I have an MSI which does the following tasks:br/
1.) Installs some files on the users machine,br/
2.) Custom Action that executes a SELECT SQL-Query after the files has been
installed.br/
br/br/
I want to show the output of the SELECT SQL-Query to be shown in the Exit
dialogbox as
Hi
I am newbie to Wix. I would like to know how to set the
TARGETDIR and the SourceDir which are specified in the wxs file.
Thanks
Satyaprakash J
--
The Palm PDK Hot Apps Program offers developers who use
I plead ignorance. Was I dumb or what.
I got it figured out. As long as the values existed, it works out. My worry
was initially my values didnt exist and that was because of a mistyped reg
property. Anyways, all is sorted out.
Thanks again Rob!
--
View this message in context:
If you look in the wix help for the Name attribute of the Shortcut
element, youll see that it has the type LongFileNameType. Properties are
only substituted into (formatted) string types.
The ProgramMenuDir value should be a directory Id so it works as you
suggested. Directory Ids are a bit
OK it seems like you're tripping over the way that some attributes are
of the Formatted type, while others aren't (see
http://msdn.microsoft.com/en-us/library/aa368609.aspx )
If you want a Property to expand into the text it is set to during
install of your package, the type of the string you're
Long Answer:
SourceDir - http://msdn.microsoft.com/en-us/library/aa371857.aspx
TARGETDIR - http://msdn.microsoft.com/en-us/library/aa372064.aspx
Short Answer:
You can't/shouldn't unless you're doing an administrative installation
in which case supply it on the command line.
Why do you want to?
Try setting Execute=immediate if you don't need the Custom Action to
run elevated (see
http://wix.sourceforge.net/manual-wix3/wix_xsd_customaction.htm). Have
you set the Return attribute in your CustomAction Element what are you
doing with the output from the SQL query? Code samples go a long way
1 - http://msdn.microsoft.com/en-us/library/aa372497.aspx
2 - Nope you'll have to do it the long way.
You'll need 2 MSI's if you want to access the 64-bit areas of the
registry on x64 platforms. MSI's are platform architecture specific.
Palbinder Sandher
Software Deployment IT Administrator
T:
Sounds to me like your original package is installed in a per-user
context but your patching system is forcing everything to run as
per-machine. If you want to force a package to always be per-machine,
set InstallScope=perMachine in your Package Element (see
http://wix.sourceforge.net/manual-wix3/wix_xsd_binary.htm
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited.
Hi,
It looks like you will only need to do the HKLM code once, if
you write it for the 32 bit version and your msi is 32 bit it will
automatically be redirected by windows to the Wow6432Node on 64 bit
operating systems.
As for the easy way sadly there is none if you don't want to write a
Hello,
I have the following XML snippet:
Directory Id=ProgramMenuFolder
Directory Id=MyAppLinkDir Name=MyApp/
/Directory
Since I'm only putting shortcuts in there I'm receiving an ICE64. I
know I could suppress this by using RemoveFolder but the thing is my
setup just installs an add-on. That
What happens if someone uninstalls the app your add-on is for then
uninstalls your add-on?
Use RemoveFolder don't suppress any ICE warnings/errors.
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design,
Hi...
I've got some old wix scripts installing msil .net assemblies
in the gac and adding registry entries for com interop. These things will work
x64 as is, so I tried the installer without making any particular changes to
the old scripts.
What I found,
But then the uninstall will remove the folder even when the original
application is still installed.
On 4 August 2010 14:59, Pally Sandher pally.sand...@iesve.com wrote:
What happens if someone uninstalls the app your add-on is for then
uninstalls your add-on?
Use RemoveFolder don't suppress
Have you actually tested it seen that behaviour?
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered
You need to set the Win64 attribute on your components. If it's not set
they default to 32-bit components in an x64 package.
An easy way to do it is to use a pre-processor variable set to no or
yes whether you're building x86 or x64 packages respectively. Then you
can simply use something like
Remove Folder only removes empty folders.
-Original Message-
From: Christian Tusch [mailto:ctu...@gmail.com]
Sent: 04 August 2010 14:49
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] ICE64, can't use RemoveFolder
But then the uninstall will remove
RemoveFolder only works on empty folders.
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: 04 August 2010 14:55
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] ICE64, can't use RemoveFolder
Have you actually tested it
No, I was just assuming since I've read that RemoveFolder is often
used to delete folders to which the application has added files
manually.
On 4 August 2010 15:55, Pally Sandher pally.sand...@iesve.com wrote:
Have you actually tested it seen that behaviour?
Palbinder Sandher
Software
If the file which is in the msi is in the Binary table, you just need to
open the MSI and extract the binary from the table (into memory).
-Original Message-
From: Muthuramakrishnan [mailto:s...@srasys.co.in]
Sent: Tuesday, August 03, 2010 12:38 PM
To: wix-users@lists.sourceforge.net
The portions of log you show here shows that Windows Installer quite clearly
thinks that the previous version is installed per-user. And this list often
looses attachments, so you may need to share the log via some other
location.
-Original Message-
From: Lukasz Zalewski
Posting again, as I wasn't subscribed to the WiX users mailing list
This isn't necessarily specific to WiX, but there's a lot of Windows install
expertise on the WiX forums and I haven't had luck posting this question to
other places. Any suggestions would be appreciated.
We're using a
Well as Peter David pointed out as the WiX
(http://wix.sourceforge.net/manual-wix3/wix_xsd_removefolder.htm) MSDN
(http://msdn.microsoft.com/library/aa371201.aspx) documentation says,
RemoveFolder only removes empty directories.
As I tried to point out, if someone removes the app your
Thanks for your replies. I just noticed I mixed it up with the
behavior of RegistryKey's Action attribute. Obviously I will go for
your solution. Thanks again!
On 4 August 2010 16:17, Pally Sandher pally.sand...@iesve.com wrote:
Well as Peter David pointed out as the WiX
Hi Palbinder
On 08/04/2010 11:50 AM, Pally Sandher wrote:
Sounds to me like your original package is installed in a per-user
context but your patching system is forcing everything to run as
per-machine. If you want to force a package to always be per-machine,
set InstallScope=perMachine in
As to the long way, you may find using the ?for? preprocessor construct
helpful to ease the code maintenance required.
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: Wednesday, August 04, 2010 3:56 AM
To: General discussion for Windows Installer XML toolset.
Given the limitations of Windows Installer UI, I don't see a way to do that
easily.
-Original Message-
From: Sagar [mailto:sagarkavitak...@gmail.com]
Sent: Wednesday, August 04, 2010 1:15 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Output of deferred custom action
Hi Blair
On 08/04/2010 03:15 PM, Blair wrote:
The portions of log you show here shows that Windows Installer quite clearly
thinks that the previous version is installed per-user. And this list often
looses attachments, so you may need to share the log via some other
location.
Here is the full
Apologies, I read patching system assumed it was MSPs not Major
Upgrade MSIs.
Point still stands though. If it works fine without using wpkg but
breaks when using wpkg, the problem isn't WiX or Windows Installer
it's unlikely to be your package.
From your log:
MSI (s) (78:4C) [20:14:06:466]:
On 08/04/2010 05:02 PM, Pally Sandher wrote:
Apologies, I read patching system assumed it was MSPs not Major
Upgrade MSIs.
Point still stands though. If it works fine without using wpkg but
breaks when using wpkg, the problem isn't WiX or Windows Installer
it's unlikely to be your package.
The log shows that there's a per-user scenario involved - there's no reason to
believe that the log is lying. This is very explicit:
MSI (s) (78:4C) [20:14:06:555]: FindRelatedProducts: current install is
per-user. Related install for product '{A70E99ED-87C6-4142-88A7-8491459494A2}'
is
On 08/04/2010 05:37 PM, Wilson, Phil wrote:
The log shows that there's a per-user scenario involved - there's no reason
to believe that the log is lying. This is very explicit:
I do not doubt that - just trying to figure out if its the new installer
that is broke or the old one.
One final
Hi All,
I recently upgrade our build toolset. Once I did that (most likely because we
moved from an older version of Wix), I started receiving this error in a couple
of projects. I initially though it might be due to a race condition (dependent
projects being built later), but it looks more
From the install log you sent the link to earlier:
What is standing out to me (from the properties, this is (I'm assuming)
installing 0.5.0 over 0.3.0 via major upgrade):
Before the sequence table is parsed:
MSI (s) (78:4C) [20:14:06:466]: Product not registered: beginning first-time
install
Thanks Palbinder.
It's good to know the VersionNT64 property. It's sad to learn I've to do it the
long way.
From: Pally Sandher pally.sand...@iesve.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Wed,
Thanks David.
I'm gonna try the HKLM in my 64 bit machine.
From: David Watson dwat...@sdl.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Wed, August 4, 2010 3:55:33 AM
Subject: Re: [WiX-users] How to copy
Thanks Blair.
I never used foreach.. I'll try that.
From: Blair os...@live.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Wed, August 4, 2010 7:54:22 AM
Subject: Re: [WiX-users] How to copy registry subkey
Our QA found an issue:
during uninstallation, if our app is minimized in systray, the FileInUse dialog
doesn't show up. That will cause crash when the end user tries to activate and
run the app - as the app is already uninstalled.
I tried it, in Windows 7, it works fine - I did see the
Hello, I like to author an MSI in such a way that it first uninstalls any
previous version using the same upgrade code. What is the key element of a wix
file that enables this scenario?
Thank you!
--
The Palm PDK Hot
It's expected because Windows 7 MSI engine has a better detection mechanism
(Restart Manager) for files in use. Prior to that it wouldn't detect apps
minimized in the system tray. Maybe WiX's close apps custom action would help.
Phil Wilson
-Original Message-
From: little.forest
I think we found similar issues. The RMFilesInUse behavior is different
in XP vs. Windows 7 and possibly in Vista as well. We ended up adding
several custom actions to try to stop our executables both with and
without elevation.
You can try the WiX util:CloseApplication to get started, but we
I have an install that has several DTF CA's in them using wix 3.0. Normally in
an MSI log I'm used to seeing something like:
1) action start
2) MSI (c) Invoking remote custom action. DLL: path Entrypoint: function
3) SFXCA: Extracting custom action to ..
4) SFXCA: Binding to CLR
http://lmgtfy.com/?q=wix+uninstall+previous+upgrade
From: Lucius Fleuchaus [mailto:luci...@microsoft.com]
Hello, I like to author an MSI in such a way that it first
uninstalls any previous version using the same upgrade code.
What is the key element of a wix file that enables this
Thanks Travis for your reply.
Yes, we tried CloseApplication, but it doesn't help.
From: Travis Gaff tra...@pc-doctor.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Wed, August 4, 2010 2:08:07 PM
Subject:
Thanks Phil.
That's what I explained to our team. So now, our team agreed that we can look
for a solution in future.
From: Wilson, Phil phil.wil...@invensys.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent:
Nevermind, I worked it out in my mind. This CA is called as a DoAction
ControlEvent.. ugh I love msi, I love msi, I love msi (repeat)
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves
attention?
MSI (s) (78:4C) [20:14:06:555]: FindRelatedProducts: current install is
per-user. Related install for product
'{A70E99ED-87C6-4142-88A7-8491459494A2}' is per-machine. Skipping...
In the above log entry, current install refers to what is already
installed (0.3.0) and related install refers to
If you use recent builds of 3.5, you can use just one element:
MajorUpgrade. Read the docs for this element for the Schedule attribute.
If you use 3.0 you have to use two elements (that the above element sets up
for you):
1. Upgrade and it's principle child UpgradeVersion.
2.
Assuming util:CloseApplication finds the app (a window owned by the app
must be enumerable using the EnumWindows() WIN32-API), the app must be
written to shutdown when windows found using that API receive WM_CLOSE
messages (and CloseApplication won't even attempt to even send that message
unless
I haven't looked back to see exactly how long ago this attribute was removed
(it exists in wixobj files from v2 but not v3-RTM) what I am wondering is if
you are either building against wixobj/wixlib files built previously instead
of compiling everything new or if you are saving wixobj files from
55 matches
Mail list logo
