and these ref counts get set on folders you might get into the
situation where the folder and therefore the files it contains cannot be
removed because there is a SharedDlls ref count on that folder. This is
just another reason to not cause msidbComponentAttributesSharedDllRefCount
to be set.
Phil Wilson
This typically means that schema of the MSI file (such as 200 for MSI 2.0)
is higher than the current version of MSI on the system.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, June 16, 2006 7:45 AM
To:
is missing when the service is started.
If it doesn'r start at reboot time, this can be a dependency on another
service that you haven't configured.
As an aside, you should look at MsiHiddenProperties as a way of not exposing
passwords in a log!
Phil Wilson
From
I don't *think* this surprises me. In the standard
search for assemblies (as in MSDN "How the runtime locates assemblies") if the
assembly is in the GAC it gets used, and if there's also one in the application
folder it gets ignored.
Phil Wilson
From: [EMAIL PROTECTED]
[mai
version of your product it will
be silently uninstalled. Whether there is an older version or not, every
install will be an install of a new product.
Phil Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter G.
Sakhno
Sent: Wednesday, July 26
Sequence the custom action before files get copied so yes, somewhere early
in the sequence is fine.
Phil Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alexander
Biryukov
Sent: Monday, August 07, 2006 1:28 AM
To: [EMAIL PROTECTED]; wix-users
This is a list of some of the possible causes for 1603:
http://support.installshield.com/kb/view.asp?articleid=Q107182
Phil Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Thursday, August 24, 2006 9:22 PM
To: Joe Kaplan
Cc
Calling Assembly.Load and checking the GlobalAssemblyCache property should
work. Another alternative might be the obscure
IAssemblyCache::QueryAssemblyInfo call (C++).
Phil Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joe Kaplan
Sent: Friday
It may be that features are what you could use. If each component is in its
own feature then users can go to the single entry in Add/Remove and choose
to add or remove each feature.
Phil Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stefan
(or add) features. Using features like this is generally safer if the two
components you're referring to are connected in some way and perhaps sharing
files.
Phil Wilson
From: vij [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 31, 2006 9:37 PM
To: [EMAIL
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
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
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
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
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.
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 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
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
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
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
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
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
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
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
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
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
...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
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
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
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
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
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
...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
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-
...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
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
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
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
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
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
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
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:
. 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
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
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
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
. 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
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
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:
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
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
... 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
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:
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
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
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 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
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
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,
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
:
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
about in-use files or restarts or services will cause that.
Phil
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Tuesday, June 04, 2013 8:06 AM
To: 'Phil Wilson'; 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] Upgrade uninstall
-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
IgnoreRemoveFailure=yes on the UpgradeVersion element. Now I
have my REP early and I will fix the custom actions to avoid this problem in
future versions. Thank you all for your help.
Date: Tue, 4 Jun 2013 11:20:22 -0700
From: Phil Wilson phil.wil...@mvps.orgmailto:phil.wil...@mvps.org
Subject: Re: [WiX
This has come up before quite recently(May 2013) in a DTF CA with a
ConnectionString.
Custom action code can interface with the MSI log to create entries there,
and because they just log a string they see they don't know whether the
content is private or not, and they do not participate in the
Just a few comments:
Deferred and before RemoveFiles makes sense, but what action is removing the
Dlls that the exe needs?
Is APPLICATIONDIRECTORY recovered and is it correct at uninstall time?
Your condition on the uninstall is incorrect. Use REMOVE=ALL as a
condition for an uninstall. The
What does the StopServices action say about stopping the failing service?
There may be something useful there.
If you have any code in your apps that starts, stops, reconfigures these
services, then take a close look at it. One of the reasons for this issue is
that somebody had a handle open to
You need something like this example of RegistrySearch that sets a property:
http://wix.sourceforge.net/manual-wix3/read_a_registry_entry.htm
You'll need a custom action to read that property, add your data creating
another propertyb that you can then write to the registry with a
RegistryValue
It's the ignoring part that is the issue, that's David's point. Properties
will not be propagated from the UI sequence (and command lines) unless they
are marked secure. Internally that's here in the MSI file:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371571(v=vs.85).as
px
So
1 - 100 of 612 matches
Mail list logo
