-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Tuesday, June 04, 2013 10:35 AM
To: 'Phil Wilson'; 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] Upgrade uninstall restart issue
I must not be understanding what you mean. As I mentioned
If you're restructuring the components and guids then you must run your REP
early to uninstall the old product before installing the new one, such as
after InstallValidate.
Your issue may be that your custom action is immediate because that means
before any files have been installed. I suspect
Those properties in the upgrade table are created when FindRelatedProducts
runs. They should be self-explanatory, but it looks like you need to use
(at a minimum) WIX_UPGRADE_DETECTED instead of OLDERVERSION_BEINGUPGRADED in
those conditions.
Phil
-Original Message-
From: Alain Forget
:
Thanks Phil, I'll take a look when I get a chance. I have a feeling
it's still in the hash table.
Thanks again.
On 30 May 2013 19:28, Phil Wilson phil.wil...@mvps.org wrote:
Have a look at the vital setting for the file. You may find it's
not vital in the Info message case.
MSI File table
Also:
Two entries in Add/Remove means the upgrade failed to upgrade. You have side
by side (or on top of each other) products running, so since the upgrade did
not in fact happen I'd say that then all bets are off regarding proper
behavior of in-use files. Check the log for FindRelatedProducts to
Have a look at the vital setting for the file. You may find it's not vital
in the Info message case.
MSI File table:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368596(v=vs.85).as
px
If the file is external and you are replscing it at the last moment make
sure you don't make a
Those sequence messages often refer to the internal file sequence and
getting things from the cab file. Trying without the cab file sometimes
gives different results. Glad you solved it, cheers.
Phil
-Original Message-
From: Spud [mailto:andysmi...@gmail.com]
Sent: Wednesday, May 29,
Try doing a build with loose uncompressed files and see if it installs ok.
It may be something to do with the sizes of the individual files or the CAB
file.
Phil
-Original Message-
From: andy smith [mailto:andysmi...@gmail.com]
Sent: Tuesday, May 28, 2013 8:58 AM
To: General discussion
I disagree
If your application needs to update files in the Program Files folder then
it needs admin privilege. If the history of the application is that it's
always worked this way, even on Windows XP, then it's always needed admin
privilege and now on UAC machines the program needs an
It's possible in this case that the initiating program is firing off
multiple separate MSI installs and not waiting for the previous one to
finish. That program Sample_1.1.0.10.exe has started this one in silent mode
and may have previously launched others.
Phil
-Original Message-
...
/Thomas
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: 21. maj 2013 18:58
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Creating patches
I think a check for the PATCH property is more typical.
Phil
-Original
I think a check for the PATCH property is more typical.
Phil
-Original Message-
From: Thomas Due [mailto:t...@scanvaegt.dk]
Sent: Tuesday, May 21, 2013 6:09 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Creating patches
I was reviewing the
a dll file ,but file version is same only the modified date is changed
When patching the file modified date gets changed to system present date in
Windows 7
Any hindsight?
Thanks and Regards
Ravi
On 5/20/2013 7:50 PM, Phil Wilson wrote:
Is this a versioned file or a data file?
Dates usually don't
Is this a versioned file or a data file?
Dates usually don't matter with versioned files - if you want to know it's
history use the version. If it's a data file Windows will set some dates
when it gets installed.
And are we talking about creation, last access, modify times?
Phil
The execute sequence runs twice, in custom action terminology the first is
immediate, when Windows is writing a script to do the install; the second
time it's deferred when applied to custom actions, when the system
actually gets changed. That means you can be after InstallFiles in an
immediate
Take a look at that folder and the file at
C:\cygwin\home\build\current\EUROPA\MyProgram.msi .
That looks like a user-created folder, and it seems that the install fails
as soon as it switches to the service to do the install. That file/folder
may not allow access by the SYSTEM account.
Phil
You could also look at ReplacedInUseFiles:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371219(v=vs.85).as
px
Phil
-Original Message-
From: John L Krupka [mailto:john.kru...@nmwco.com]
Sent: Friday, May 17, 2013 10:32 AM
To: wix-users@lists.sourceforge.net
Subject:
... And it doesn't have to an issue in your MSI. There seems to be a problem
where the system account loses access to some folders, so see if this is the
issue, like this:
http://support.microsoft.com/kb/228658
And try it on some other fresh virtual machines to see if it's happening
everywhere
A) What exactly does installing a new version of my application mean? Is
it a patch, a major upgrade, an update by reinstalling the new MSI file?
B) It's not clear to me why the application (apparently randomly) prompts to
save information. We can assume it's closing down, but if the install
will agree that this is a crutch.
2013/5/12 Phil Wilson phil.wil...@mvps.org
It's best to create a verbose log of the upgrade and then search for
the file name to see what it says about overwiting the file and why it
didn't.
Phil
-Original Message-
From: Candy Chiu [mailto:candy.chiu
It's best to create a verbose log of the upgrade and then search for the
file name to see what it says about overwiting the file and why it didn't.
Phil
-Original Message-
From: Candy Chiu [mailto:candy.chiu...@gmail.com]
Sent: Friday, May 10, 2013 6:56 PM
To:
Major upgrades have a property that gets set when the older version is
found. To use Bob's example:
!- Major upgrade -
Upgrade Id=$(var.UpgradeCode)
UpgradeVersion Minimum=$(var.ProductVersion) OnlyDetect=yes
Property=NEWERVERSIONDETECTED /
UpgradeVersion Minimum=1.0.0
It's more likely related to something that is no longer correct during the
uninstall. Between DeleteServices and InstallFinalize the items that are
uninstalled include registry entries, type libraries, environment variables,
files, and folders.
Deferred and before InstallFinalize basically means
. It's pretty
simple (no environment variables, etc.). It produces an MSI that can be
installed but not uninstalled.
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: Friday, May 10, 2013 10:22 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re
. And the only thing I can think of that by design will not overwrite
according to file version rules is the NeverOverwrite flag in the Component.
If that was ever set for that guid on a system then it will be sticky on
that system. It can't be turned on or off in an MSI file to change the
displayed in plain
letters...
Steve
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: May-03-13 2:27 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in
MSI log
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file
Are they setting a property within their CA called ConnectionString?
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: Monday, May 06
...and at the risk of stating the obvious, custom actions can put messages
in the MSI log by calling MsiProcessMessage(). That's a good thing of
course, except when it gives away secrets ;)
Phil
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: Monday, May 06
The way it works in MSI isn't really mysterious. Basically the property name
needs to be public (and that means it must be all uppercase). If WiX does
its thing properly then you can open the generated MSI file with an editor
such as Orca, look in the Properties table, and in the Property table
CA_WebAppPoolPassword.SetProperty that was
displaying the property in the MSI log file.
Took it out and now the password is not being displayed in plain letters...
Steve
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: May-03-13 2:27 PM
To: 'General discussion for Windows
=[WEBAPPPOOL_PASSWORD]
Order=91/Publish
It was the custom action CA_WebAppPoolPassword.SetProperty that
was displaying the property in the MSI log file.
Took it out and now the password is not being displayed in plain
letters...
Steve
-Original Message-
From: Phil Wilson [mailto:phil.wil
I had the same issue with RunOnce. The solution was to create the RunOnce
data in a file and have the RunOnce key start the program with a command
line that said hey, the data you want is in this file.
Phil
-Original Message-
From: rowbot [mailto:jamesnrow...@yahoo.co.uk]
Sent:
.. And this example describes it:
http://www.joyofsetup.com/2010/01/16/major-upgrades-now-easier-than-ever/
And note that RemoveExistingProducts is early in the sequence, after
InstallValidate, and that results in removal of the oler product before
installing the new one.
I don't know what a
. And determining the size of an MSI can be a royal pain. If you mean
when it's about to be installed then it will be accurate only after the
costing is complete because features have been picked and Windows has worked
out which files are actually going to be installed. If you just want a
anything that
other programs use (at least I can't imagine how that can happen).
Alain
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: April 14, 2013 15:52
To: 'General discussion for Windows Installer
You may need to say what can't uninstall means. Does it crash and rollback
because of a custom action, or something similar? Have you forgetten the
ProductCode?
Phil
-Original Message-
From: Marco Tognacci [mailto:mark...@live.it]
Sent: Monday, April 15, 2013 12:08 PM
To:
If your downgrade is effectively the same as an uninstall of the old product
followed by an install of the new product you should be ok, and that depends
on early sequencing of RemoveExistingProducts.
If your RemoveExistingProducts is at the end somewhere, the upgrade is like
a merge of the
Ok, tell me I've got this wrong, but as far as I know there's a Powershell
download to redistribute this, so I don't know what's going with
non-Microsoft redists. In addition, it gets installed in the GAC (at least
from Windows 7 on), which makes file version somewhat less important - I
believe
Does old installshield... mean that that they didn't generate MSI
installs? If you used an InstallShield that generated MSI setups then just
use major upgrade.
Phil W
-Original Message-
From: ptr [mailto:ptrajku...@gmail.com]
Sent: Tuesday, April 09, 2013 10:43 AM
To: General
If this is a 32-bit component then it will go in WoW6432Node in the registry
on a 64-bit machine, and you may not be looking there.
Phil W
-Original Message-
From: David Steadman [mailto:steadm...@gmail.com]
Sent: Monday, April 08, 2013 6:51 AM
To: General discussion for Windows
I don't know about Burn, but there are certainly enough APIs to open a
database, apply a transform, and then enumerate the features and feature
descriptions and titles. You don't need the session object. Basically you
need SQL queries. In the script world you open the database and apply your
You could try the Win32 MsiDatabaseApplyTransform(), that's
Database.ApplyTransform in the scripting world. The problem is that the
scripting object model doesn't appear to provide navigation from installer
functions that apply to product installation, and database functions that
apply to the MSI
...but if you mean the installed data about the components, I think you need
to use MsiEnumComponents() and then for each component guid you can use
MsiEnumClients to find out which product guids they belong to (they may be
shared between several).
MsiGetComponentPath() will give you the path
I don't believe this is anything to do with WiX.
The underlying API (SRSetRestorePoint) has no callback to show progress, so
if this code is in WiX there's nothing it can do. If it's being done by
Windows as part of the MSI install there's likewise very little you can do
about feedback other
These are not command line choices I've seen or used. Why not those listed
here?
http://msdn.microsoft.com/en-us/library/windows/desktop/aa372104(v=vs.85).as
px
Phil
-Original Message-
From: robe070 [mailto:goodridge@gmail.com]
Sent: Wednesday, March 27, 2013 5:38 PM
To:
In the same way you add conditions to any action such as a custom action -
there's nothing different.
As a rule, there's no need to add a condition to REP because it does its
thing only if an upgrade has been detected. What problem are you trying to
solve?
Phil
-Original Message-
...and on this issue:
When I uninstall this package, the system complains that the file is in use
(it *is* in use; it is a shell extension to windows explorer).
This only happens when it is a lowly user that is trying to uninstall this.
I thought that the registry registration/deregistration
...so somebody doing an upgrade needs to decide which option to use, and
it's typically based on the scope of the changes.
Just changing a few binaries means a patch is a lightweight option for
customers.
More major changes (adding files, updating files, new custom actions)
typically mean
Yes, the Installed property means this ProductCode is installed. If you
see that Welcome dialog again the most obvious thing to check is whether the
ProductCode has changed. The idea is that you only see the Welcome dialog on
fresh first time install. Later actions based on the same ProductCode
Ah, the other explanation is that you installed that MSI in a per User
context, and now you're installing it a different user context (another user
or per System).
Phil
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: Friday, March 22, 2013 9:51 AM
To: 'General
It's missing because it's part of the VS setup infrastructure for creating
web sites, not part of WiX. I don't know what added the custom action
actually means there, but because it's a piece of VS setups, WiX won't have
that Dll, you won't know it's dependencies or limitations (which IIS
versions
... and there's something about conflating a system activity (patch
uninstall) with database rollback that would make me nervous. ;)
However, MSI 4.5 and later does have a patch uninstall custom action, that
might be an option, but my inclination would be to use it to set a flag
somewhere so
Rob answered in StackOverFlow
Phil
-Original Message-
From: Eddy Ukstein [mailto:edd...@gmail.com]
Sent: Wednesday, March 20, 2013 7:21 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] 64bit custom actions
I described the problem here few days ago:
: pixelink.mogilvie www.pixelink.com
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: Tuesday, March 19, 2013 5:34 PM
To: 'General discussion for Windows Installer XML toolset.'; afor...@cmu.edu
Subject: Re: [WiX-users] Uninstall
The file paths may
of:
File: C:\Program Files\Qualisystems\TestShell Server\QS.Contracts.dll;
Overwrite; Won't patch;REINSTALLMODE specifies all files to be
overwritten
For all the files in the patch... even though the log specifies it's gonna
overwrite... it dones't.
-Original Message-
From: Phil
The file paths may be in the SharedDlls registry entries,
HKLM\Software\Microsoft\CurrentVersion\SharedDlls.
If you ever marked them shared or permanent and installed them, then they
are stuck on the system. Changing the guid won't help if they're permanently
on the system under another guid, or
You shouldn't use MessageBox. MsiProcessMessage() is the right way,
typically with INSTALLMESSAGE_USER.
Phil
-Original Message-
From: StevenOgilvie [mailto:sogil...@msn.com]
Sent: Wednesday, March 13, 2013 12:05 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Any ideas on
XML toolset.
Subject: Re: [WiX-users] Any ideas on how to solve MessageBox focus, can be
lost (using Custom Action DLL)
Classification: Public
I am using a C# dll and I can't seem to find info on how to use
MsiProcessMessage() in C#
-Original Message-
From: Phil Wilson [mailto:phil.wil
...and to exapand on that, look for your files in the log. There should be a
FileCopy that will say something like Won't Overwrite;Won't patch;
and give you a reason.
If your patch is incorrect because of component rules, look for SELMGR in
the log and any remarks about removing
WiX doesn't make a habit of documenting (duplicating) Windows Installer
docs. These are the update rules for versioned files:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa367835(v=vs.85).as
px
And you are probably confusing AssemblyVersion that's used for client
binding with
Assuming you're using the DTF framework for managed code CAs, does your NET
Remoting interface into the service have authentication? If authentication
requires use of the installing user's credentials then your CA needs to use
impersonation, and if it also requires admin type privilege then you'll
You have a .bat file for the name - that doesn't seem correct to me. The
ServiceInstall table in an MSI file requires a service executable.
Phil
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Sunday, February 17, 2013 7:36 AM
To: wix-users@lists.sourceforge.net
You can use conditions in the custom action based on this:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368012(v=vs.85).as
px
Scrool down to feature and component state, and this:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368561(v=vs.85).as
px
gives examples.
The thing to look for in the log of of the upgrade is the
FindRelatedProducts data. It will tell you if it found anything, even if
it's the wrong context (per user etc) to do the upgrade.
Phil
-Original Message-
From: Helge Kruse [mailto:helge.kr...@gmx.net]
Sent: Friday, February 15,
circumstance
Hi Phil,
That link came up with a content not found page!
Any alternative?
Ches
Sean.
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: 17 February 2013 19:01
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] run a custom
one
record of the Upgrade table.
K:\MSI Packages\MSI_Prompt\UPGRADE-TEST.XML(33) : error LGHT0204 :
ICE61: Upgrade.ActionProperty OLDERVERSIONBEINGUPGRADED may be used in only
one record of the Upgrade table.
- Finished
Error in light
On 2/11/2013 8:50 PM, Phil Wilson wrote:
There's
There's nothing about the underlying Upgrade table in the MSI file that
prevents one product from upgrading several.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa372379(v=vs.85).as
px
Phil
-Original Message-
From: Vern Graner [mailto:v...@txis.com]
Sent: Monday, February
WiX requires that anything you actually reference does really exist
somewhere. That's a general rule that you should focus on. I Darked many
MSIs and got this type of error because many other tools don't check that
something you use (such as a custom action) is actually specified somewhere.
So
This is dangerous territory. The docs explicitly say you can't do this:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa367451(v=vs.85).as
px
And generally you need two MSI files for different architectures:
http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-req
If you do a web search on where is the default search engine registry
there are a bunch of articles about where it's stored. Because it's a
registry key, the WiX work is just setting the required keys to whatever
values you want.
Phil
-Original Message-
From: David Baker
My experience with this is that it works better when you make the service a
feature, hidden if necessary. The issue is that things like repairs will
need you to preserve the property state otherwise you'll do a repair or add
a feature and the property will have the wrong value. Plus if it is a
thank you for
the help.
Message: 4
Date: Tue, 15 Jan 2013 12:50:13 -0800
From: Phil Wilson phil.wil...@mvps.orgmailto:phil.wil...@mvps.org
Subject: Re: [WiX-users] Using Microsoft.Deployment.WindowsInstaller.
To: 'General discussion for Windows Installer XML toolset.'
wix-users
For these APIs to work in the way you want each file must be in its own
component. You're enumerating components by component guid, and what you'll
get returned is the key path file in the component. If the component
contains a bunch of other files it can't tell you. The key file needs to be
The issue appears to be this from the log:
=
Product registered: entering maintenance mode
Determined that existing product (either this product or the product being
upgraded with a patch) is installed per-machine.
==
..meaning that the same product is being
Well a verbose log should tell you something about what's going on, that's
typically the first thing to look at in these situations.
The comment about modified files: the standard way that Windows deals with
binary file updates in service packs, patches etc is version-based. Windows
doesn't
See the Shortcut table docs:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371847(v=vs.85).as
px
Where the Name is not Formatted type. In contrast Arguments is Formatted, so
it can be initialised dynamically from (say) a property name in square
brackets.
Phil
-Original
The Registry table uses # as the prefix to say you want an integer number,
and your string is not a number.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371168(v=vs.85).as
px
The docs say two # characters should be used, the first will be ignored and
the rest treated as the string.
Where does the REPAIR property come from? It's not a standard Windows
Installer property, so it'll be false and the custom action will be called.
A verbose log will show property values and if the CA is being called.
What does Uninstall_Component do? I don't know how or why you would use code
to
These are the file replacement rules:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368267(v=vs.85).as
px
older date isn't part of a file replacement rule for non-versioned files,
only a difference between modify and creation dates that indicate that the
file has been replaced.
You could indeed do something like this, but there is no need because there
are plenty of APIs to do this the correct way.
Combining APIs like MsiEnumProducts, MsiEnumComponents and MsiEnumClients
will return the installed products, components, and the list of products
that own a particular
Chris said when you schedule REP, meaning that its sequence determines the
behavior you get, as here:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371197(v=vs.85).as
px
The 3rd choice (between InstallExecute) has the behavior you want,
updating files using file replacement rules
Things like this are often related to the account that the CA is running
with. If it's impersonation=no (and if that's the syntax) it's running with
the system account and accessing localhost might count as network access
that the system account usually cannot do. It works when you run ldpa.exe
The main pitfalls are likely to be the default overwrite rules. If you are
referring to versioned binaries then Windows won't replace a versioned file
with one of a lower version for the (hopefully) obvious reason that a higher
version means a later improved version. Data file overwrite rules
There are some things you can do based around the MsiSourceListAddSource ()
function (and scripting equivalents) that let you define alternate paths to
locate the MSI that Windows requires. So you can put it on a network server
and then tell Windows to look there for repair (or adding features
It's hard to be specific, but it looks like the dialog you're using with its
BrowseFolder result is not propagating the user input to TARGETDIR or
INSTALLFOLDER.
Phil W
-Original Message-
From: Gavin Bray [mailto:gavb...@gmail.com]
Sent: Tuesday, October 23, 2012 11:29 PM
To:
See the docs for ComponentId here:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368007(v=vs.85).as
px
It's allowed. It just means it won't be managed by Windows, meaning amongst
other things that you'll need to remove it yourself.
Phil W
-Original Message-
From: Uma
Your previous install was per user, the new install is per machine, and one
will not upgrade the other. The Windows default if unspecified is per user,
so perhaps if you never set it in the original install it defaulted to per
user. A verbose MSI log of the install of the original could be useful
and adding some detail about did not work would help. Maybe you saw
an msiexec message box showing the correct syntax because yours was
incorrect, or maybe it started and failed in some way.
Phil W
-Original Message-
From: Rob Hamflett [mailto:rob_hamfl...@sn.scee.net]
Sent:
Error 1638 isn't related to anything you do internally by denying certain
installs for your own internal reasons. It's returned when the install
cannot even proceed because you're trying to install a package with the same
ProductCode (or PackageCode) as one that's already installed, but with a
The devil is in the details. A verbose log is the best way to see exactly
what's going on. For example, if Windows already knows that it will need to
reboot at the end of the install then it won't bother prompting to close
down any apps. What's the point?
Phil
-Original Message-
From:
You can write a custom action that uses the MsiProcessMessage (or
equivalent) call with INSTALLMESSAGE_FILESINUSE to cause a FilesInUse dialog
to display, as long as you populate the required record in the right way.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371614(v=vs.85).as
px
cannot seem to get that to work either. I
have followed all of the steps outlined in:
http://wix.sourceforge.net/manual-wix3/wixexitearlywithsuccess.htm but I see
the same results.
Thanks,
Carl
Phil Wilson phil.wil...@mvps.org 10/17/2012 11:31 AM
Error 1638 isn't related to anything you do
If you want to transform an MSI that's already installed then generate a
patch to do it. Transforms must be applied at the same time the MSI is
installed.
Phil
-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
Sent: Tuesday, October 09, 2012 4:38 AM
To:
I'd say it was more than a recommendation. The docs explicitly say that
32-bit packages can contain only 32-bit components, so with any 32-bit
components you're pretty well bound to making a package for 32-bit and
another for 64-bit.
A verbose log might show you why it wants to reboot, and it's not clear to
me why an install would offer a FilesInUse situation - you're registering an
extension, but I don't see why Outlook is using anything that you're
changing. Uninstall is clearly different because you are deleting an
If the service literally starts and stops without following the proper
service protocols, then Winmdows will give you that message about Some
services stop. It means that your service didn't do anything. If it
looks for some resource and exits if it can't find it, then that's the
issue.
The
Recursive MSI installs don't work (an oversimplification, but a complete
explanation is too complex). General approaches are to use Burn to install
them separately, or to have one be a prerequisite for the other. This
restriction is why VC Redist runtimes and other MSI-based setups are never
run
Is there some reason you cannot use the standard property System64Folder?
Phil W
-Original Message-
From: Phil Hannent [mailto:p...@elmstonesystems.co.uk]
Sent: Monday, August 20, 2012 2:30 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] 64bit
Look in the Application Event log for an MsiInstaller entry, basically a
repair for something that's probably user-profile related. The issue isn't
so much admin or not, it's just that another user is trying to reference
something that's user profile related, it isn't there, so the
IMO it's better to do this as part of the first run of the app, as somebody
mentioned already. After all, the key is to USE the software, not install
it, right?
Calling UI custom actions from an install is tricky. It's less tricky in the
UI sequence, but why bother when you can use an MSI
501 - 600 of 612 matches
Mail list logo
