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 o
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
If you use recent builds of 3.5, you can use just one element:
. 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. and it's principle child .
2. placed under . The key
is in the sequencing (set usi
>> 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
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? E-Ma
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"
To: General discussion for Windows Installer XML toolset.
Sent: Wed, August 4, 2010 2:08:32 PM
Subject: Re: [WiX-user
Thanks Travis for your reply.
Yes, we tried CloseApplication, but it doesn't help.
From: Travis Gaff
To: General discussion for Windows Installer XML toolset.
Sent: Wed, August 4, 2010 2:08:07 PM
Subject: Re: [WiX-users] FileInUse doesn't work in XP?
I thin
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
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 version
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
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 [mai
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 App
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 FileInUse
Thanks Blair.
I never used foreach.. I'll try that.
From: Blair
To: General discussion for Windows Installer XML toolset.
Sent: Wed, August 4, 2010 7:54:22 AM
Subject: Re: [WiX-users] How to copy registry subkey which includes someentries
As to the "long wa
Thanks David.
I'm gonna try the HKLM in my 64 bit machine.
From: David Watson
To: General discussion for Windows Installer XML toolset.
Sent: Wed, August 4, 2010 3:55:33 AM
Subject: Re: [WiX-users] How to copy registry subkey which includes someentries
Hi,
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
To: General discussion for Windows Installer XML toolset.
Sent: Wed, August 4, 2010 3:39:46 AM
Subject: Re: [WiX-users] How to co
>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
MS
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 lik
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 thi
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 per-ma
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
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:46
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 fu
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
As to the "long way", you may find using the 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.
Subject: Re
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" i
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 wrote:
> Well as Peter & David pointed out & as the WiX
> (http://wix.sourceforge.net/manual-wix3/
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 add
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 bootstrapper around our MSI that exercises the
MsiSetExternalUI API to redi
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 [mailto:lu...@eecs
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
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 wrote:
> Have you actually tested it & seen that behaviour?
>
> Palbinder Sandher
> Software Deployment & IT Administr
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 & se
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 the
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
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 **
Integrated Environmental Solutions Limited. Registered in Scotland No. SC1
But then the uninstall will remove the folder even when the original
application is still installed.
On 4 August 2010 14:59, Pally Sandher wrote:
> 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/err
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, though
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, Simulat
Hello,
I have the following XML snippet:
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 means I don't want to remove the
folder. Is my only option to suppress ICE64?
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
c
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 **
Integrated Environmental Solutions Limited. Registered in Scotland
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
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:
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 w
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
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 pu
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 speci
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:
http://windows-
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
Hi,
I have an MSI which does the following tasks:
1.) Installs some files on the users machine,
2.) Custom Action that executes a SELECT SQL-Query after the files has been
installed.
I want to show the output of the SELECT SQL-Query to be shown in the "Exit
dialogbox" as scrolltext.
What is cre
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
www.f
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
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 in
54 matches
Mail list logo
