There should be something earlier in the log that says what's going on. The
part of the log you posted is just info confirming it's going to do a reboot
and use those files, not the actual reason it created them in the first place.
If you search for -reboot- there may be something earlier than
You don't need a custom action. All you need is a registry item that has [Your
property name] in it, and Windows Installer will do the rest.
However.
When a property is being passed from the UI sequence into the execute sequence
it needs marking as secure so it goes into the
Sometimes these are dependency issues, C runtime support etc. Dependency Walker
is a useful tool to deal with those issues.
Phil W
-Original Message-
From: Joe Damato [mailto:j...@boundary.com]
Sent: Thursday, June 21, 2012 12:44 PM
To: General discussion for Windows Installer XML
It's just a property - use it as a condition on anything you don't want to
repeat, such as NOT AFTERREBOOT.
-Original Message-
From: victorwhiskey [mailto:victorhwhis...@yahoo.com]
Sent: Tuesday, June 19, 2012 9:38 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users]
RESUME appears to be the special case that the system rebooted during the
installation.
http://blogs.msdn.com/b/windows_installer_team/archive/2005/09/19/470980.aspx
Phil W
-Original Message-
From: victorwhiskey [mailto:victorhwhis...@yahoo.com]
Sent: Wednesday, June 20, 2012 8:49
OLD_VERSION_FOUND is not standard property, so my guess is that it's set via a
search or the Upgrade table in the new MSI that you are installing.
UPGRADINGPRODUCTCODE is set in an uninstall when it is being upgraded by a new
product.
Phil W
-Original Message-
From: Ravi Raj
UPGRADINGPRODUCTCODE is set in the product being *uninstalled*, the target of
the RemoveExistingProducts, not in your code that is calling it. If you want to
have a dialog because your setup has detected that it is upgrading an older
existing product, then base that dialog on the property being
There's this, not official but useful...
http://blogs.msdn.com/b/oldnewthing/archive/2007/09/17/4948130.aspx
Phil W
From: Jerra [beddel...@gmail.com]
Sent: Tuesday, June 12, 2012 12:22 AM
To: General discussion for Windows Installer XML toolset.
This describes how to do it, but I don't know how (or if) it shows up an MSI
log:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371614(v=vs.85).aspx
and scroll down to INSTALLMESSAGE_COMMONDATA.
-Original Message-
From: Rob Hamflett [mailto:rob_hamfl...@sn.scee.net]
, Wilson, Phil phil.wil...@invensys.comwrote:
Component or feature conditions work much better in circumstances like
this, a couple of examples that are by no means a complete list.
1. Something breaks in your product that running the custom action
would correct. You would ask the customer to go
Component or feature conditions work much better in circumstances like this, a
couple of examples that are by no means a complete list.
1. Something breaks in your product that running the custom action would
correct. You would ask the customer to go to Add/Remove ProgramsFeatures and
use
Most likely your code is crashing, the custom action, if the subject line is
the issue. That part of the log would have been more useful. that something
about Win64. My guess is that you have an uninstall custom action which assumes
that the properties you are using (SERVERNAME, DATABASENAME)
accustomed to C++.
On Wed, May 30, 2012 at 1:36 AM, Wilson, Phil phil.wil...@invensys.comwrote:
MsiProcessMessage might be what you should be using, with
INSTALLMESSAGE_USER.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa370354(v=vs
.85).aspx
Phil W
-Original Message-
From
MsiProcessMessage might be what you should be using, with INSTALLMESSAGE_USER.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa370354(v=vs.85).aspx
Phil W
-Original Message-
From: Ravi Raj [mailto:raviraj.callin...@gmail.com]
Sent: Monday, May 28, 2012 2:43 AM
To: General
Those top two are Visual C++ 2010 C runtime support Dlls, typically supplied
with this type of thing:
http://www.microsoft.com/en-us/download/details.aspx?id=
or with merge modules that came with Visual Studio 2010. You'll probably need
a minimum of XP SP3 (see the link, system
It might actually be working for per-user...
A genuine per-user COM registration will be in HKCU for the installing user -
it won't be exposed to the entire system. In what sense is it not working?
Phil W
-Original Message-
From: vasjko [mailto:vas...@ua.fm]
Sent: Wednesday, May 23,
WiX has a tool for extracting COM information, it's harvested using heat.exe.
Even if you wanted to have the Dll self-register you don't need to do that by
running regsvr32 because Windows Installer has a SelfReg table, just get your
Dll in there.
Developers often think that installs work
{6F0D9A8
0008: 41 2d 34 39 37 34 2d 34 A-4974-4
0010: 30 37 41 2d 42 34 42 33 07A-B4B3
0018: 2d 37 31 31 32 37 43 39 -71127C9
0020: 46 46 34 38 30 7d FF480}
On Wed, May 23, 2012 at 3:02 PM, Wilson, Phil phil.wil...@invensys.comwrote:
WiX has a tool for extracting COM information, it's
Just to add the doc link:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa367451(v=vs.85).aspx
Phil W
From: Bob Arnson [b...@joyofsetup.com]
Sent: Friday, May 18, 2012 9:13 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users]
That's probably normal. I don't know the actual implementation, but assuming
it's based on MsiProcessMessage and INSTALLMESSAGE_PROGRESS the documentation
says that progress can go backwards. There's probably a joke somewhere in
there...
Phil W
-Original Message-
From: Bruce Cran
In cases where the user chooses features from a dialog, that dialog is after
CostFinalize in the MSI files I've looked at, so feature-action is unknown.
Maybe it's correct after CostFinalize if you've specified features in advance
on the command line, but I don't know if that's what you're
Windows Installer folder properties include a backslash. Try:
'[System64Folder]bcdedit.exe
Phil W
-Original Message-
From: Vincent Wong [mailto:victorhwhis...@yahoo.com]
Sent: Friday, May 11, 2012 1:23 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re:
...which is why I suggested deleting that extra \ as something to try.
-Original Message-
From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
Sent: Friday, May 11, 2012 2:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Does wix
Not sure if this has been mentioned, but one of the gotchas is that the
previous version of the install might be installed per-user instead of
per-machine. A per-machine install will not upgrade a per user (and vice versa)
so you get two entries in ARP. That's an InstallShield log, not an MSI
Are you maybe misunderstanding the FilesInUse dialogs? Windows decides to show
this or nor based on what files need replacing, whether they are in use, their
versions etc. CloseApplication is not the same thing at all - it's a WiX
feature that closes applications.
Phil W
-Original
That HRESULT is FUSION_E_UNEXPECTED_MODULE_FOUND.
http://blogs.msdn.com/b/astebner/archive/2004/11/10/255346.aspx
Is there a config file associated with the assembly (maybe because it's a
policy assembly)?
Is it actually a Dll?
Phil W
-Original Message-
From: Sam Youtsey
And the TLB file is in the same component as the assembly or is somehow being
installed to the GAC? That could explain an error
FUSION_E_UNEXPECTED_MODULE_FOUND.
Phil W
-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: Thursday, April 26, 2012 12:35 PM
To:
Well you can install assemblies (that supply COM interfaces) into the GAC. But
you are trying to install a Win32 COM DLL into the GAC? That won't work, and
it's not a WiX issue - it doesn't matter what you use to build your MSI file
because it's MSI that's doing the install.
If it's Win32
You really have to say if it's a Win32 COM Dll or not. I can't see a definitive
statement one way or another. However if it is Win32 COM, just use Heat.exe to
generate the WiX source for the registration.
Phil W
-Original Message-
From: Sam Youtsey [mailto:sam.yout...@gmail.com]
Sent:
A couple or three notes on causes:
1. A ResolveSource action with an incorrect condition can cause this, something
that may be worth checking.
2. Any kind of update requires Windows to see if an incoming versioned file has
a higher version than the one on the system. Some people do out-of-band
Heath's article probably applies
http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx
Phil W
-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Tuesday, April 10, 2012 10:55 AM
Do you have any more details of the error? The normal behavior in full UI mode
is that you will see an error message and the install transaction will roll
back.
Phil W
-Original Message-
From: Niklaus Pham [mailto:niklaus.p...@gmail.com]
Sent: Sunday, April 08, 2012 12:14 AM
To:
=InstallFinalizePREVIOUSVERSION_AGPM_FOUND/RemoveExistingProducts
On Thu, Mar 29, 2012 at 1:42 PM, Wilson, Phil phil.wil...@invensys.comwrote:
The other placement of RemoveExistingProducts is in a sequence at the end
typically something like:
PublishProduct
InstallExecute
RemoveExistingProducts
InstallFinalize
So
/2012 1:40 PM, Wilson, Phil wrote:
There may not be enough context in that WiX to see what actually gets
generated in the MSI file. That sequence is certainly allowed because other
tools have been generating it for years.
Phil W
-Original Message-
From: Meera Jindal
The other placement of RemoveExistingProducts is in a sequence at the end
typically something like:
PublishProduct
InstallExecute
RemoveExistingProducts
InstallFinalize
So there is room for your deferred CA in that gap between REP and
InstallFinalize.
Phil W
-Original Message-
Doing the upgrade with a verbose log will tell you if it's finding the previous
product. One gotcha when everything else looks correct is that the older
install could have per user (or per system) and your upgrade is the opposite.
Phil W
-Original Message-
From: Daniel Sniderman
You can't set MsiLogFileLocation, as the MSDN docs pretty much say. You can try
to set it but it's ineffective. If you set it in the property table it just
gets overwritten. If you set it with a type 51 it just gets ignored.
Phil W
-Original Message-
From: Alec Swan
in version x.x or This
is how you do this ... - it will still be very helpful.
Thanks,
Alec
On Thu, Mar 15, 2012 at 11:32 AM, Wilson, Phil phil.wil...@invensys.com wrote:
You can't set MsiLogFileLocation, as the MSDN docs pretty much say. You can
try to set it but it's ineffective. If you set
Transforms are transforms - they apply to the MSI file, not just the UI. I've
changed Shortcut names, custom action conditions and (I'm pretty sure)
ProductName using transforms.
Phil W
-Original Message-
From: Dave Mateer [mailto:dave_mat...@ntm.org]
Sent: Tuesday, March 13, 2012
CustomActionData is actually per custom action, although it sometimes appears
that there is only one for all custom actions. Basically, if you have a custom
action called Fred that you want to pass data into, you create an immediate
set-a-property custom action (type 51 in MSI) that sets Fred
Assuming that you have that custom action in both old and new setups, take a
look at the entire log. It might be happening when the old install is being
removed and the service is really not there because the condition doesn't look
right to me, if my thinking is correct.
NOT ((REMOVE~=ALL)
Maybe and no. You should be looking at the Windows Installer properties for
locations. There are properties such as ProgramFilesFolder and
ProgramFiles64Folder that resolve to those locations at install time. In your
case, the more useful one is the FileKey property for your file.
Raymond agrees with you ;=)
http://blogs.msdn.com/b/oldnewthing/archive/2007/09/17/4948130.aspx
Phil W
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Tuesday, February 28, 2012 7:06 AM
To: General discussion for Windows Installer XML toolset.
Subject:
6.1.98.16 was a security update, and I don't believe new merge modules were
ever supplied.
The Windows Installer default file replacement rules mean that 6.0.88.4 should
never replace a 6.1.98.16. I suspect that something non-standard is going on.
You're not updating with a REINSTALLMODE
I suspect a LoadUserProfile is done for the user in question. That's what
contains those kinds of paths etc.
Phil W
-Original Message-
From: Andy Clugston [mailto:clug...@gmail.com]
Sent: Wednesday, February 22, 2012 11:04 AM
To: General discussion for Windows Installer XML toolset.
It depends on what you put in your ServiceControl for the service, but the do
I need to show FilesInUse is smart enough to check the ServiceControl table in
the MSI file, and if there's an entry that says stop at uninstall time then
there's no need for FilesInUse because the service is going to
C++ custom actions have a defined signature that includes expected return
values.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368072(v=vs.85).aspx
You may be able to store the message in a property or anywhere else (registry?)
to retrieve later.
Phil W
-Original
Where is your RemoveExistingProducts sequenced? If it was towards the end, the
upgrade would behave more like an update and replace only files with higher
versions and not replace altered data files (when they have the same component
guid).
BTW Permanent really means permanent. It's a setting
It could be a services dependency - you'd see that in the services applet.
Make sure that there isn't something in the ServiceControl table even if it's
just spaces that might not show. I've noticed that spaces can affect this kind
of thing. It might literally be trying to stop a service
You know that MSI setup projects in Visual Studio are disappearing anyway,
right? See retirement note at the top of these forums:
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/threads
Phil W
-Original Message-
From: Michael Powell [mailto:mwpowel...@gmail.com]
Sent:
Service can't start can be a dependency issue. A service that's dependent on
Dlls being installed to the GAC or to SxS (C++ runtimes) will fail when MSI
starts because StartServices is before these are committed to the system. It
will start from Service Control Panel afterwards (if there's no
And in the verbose log, see if there are any SELMGR entries. They indicate that
you've broken component rules during a patch by deleting a component. Otherwise
look at the log to see what it says about that particular file and why it
didn't replace it.
Phil W
-Original Message-
You might need an Error table in your MSI file. I think an empty path is an
error related to the SQL query not finding anything.
Error should be a standard table, but the log seems to think there isn't one,
assuming that really is the issue. I thought WiX used the SDK's schema.msi as a
base?
In the ServiceControl element that starts your service, what's your Wait value?
It's not documented in MSDN, but AFAIK a Wait value of 1 causes a wait for the
Service to start successfully and if it fails the install will roll back.
Phil W
-Original Message-
From: Jeremy Farrell
Log in won't cause replication of the keys. An earlier post mentioned that you
need an advertised shortcut.
Phil W
-Original Message-
From: McCain, Jon [mailto:jon.mcc...@inin.com]
Sent: Friday, January 13, 2012 8:06 AM
To: chr...@iswix.com; General discussion for Windows Installer
to run a command line often is ;)
Phil
From: Christopher Painter [mailto:chr...@iswix.com]
Sent: Friday, January 13, 2012 12:40 PM
To: Wilson, Phil; General discussion for Windows Installer XML toolset.; Dan
Gough
Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all
users
And the MSDN docs *recommend* RunOnce as a way to finish application setups. It
does seem unfair for an AV product to decide to prevent completion of
application setup. InstallShield uses the RunOnce key too, judging from search
hits and their content.
Phil W
-Original Message-
:55:420]: Component: Client; Installed: Local;
Request: Absent; Action: Absent
MSI (s) (B0:48) [15:02:55:420]: Component: My_Instrument_Server; Installed:
Local; Request: Absent; Action: Absent
Thanks,
Yannick A
Wilson, Phil-2 wrote
That log extract is not necessarily anything to do
That log extract is not necessarily anything to do with the problem.
1. Was the service executable removed?
2. Was the service entry removed from the service applet.
3. Are you using ServiceInstall elements to install/uninstall the service?
4. What does the log say about the component state
the
installed product upgrade code how do I find that product architecture?
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Thursday, January 05, 2012 18:58
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Querying
If it's working ok you should get a result something like Intel64;1033or
Intel;1033that tells you that.
Phil W.
-Original Message-
From: Alex Ivanoff [mailto:aivan...@vmware.com]
Sent: Thursday, January 05, 2012 10:30 AM
To: 'General discussion for Windows Installer XML toolset.'
That error message should have more detail if you produce a verbose log. The
error is:
2819
Control [3] on dialog [2] needs a property linked to it.
So the log should tell you the name of the control.
Phil W
-Original Message-
From: Rohini S [mailto:roh...@lucidindia.com]
Sent:
There is a hotfix available, not sure if this has been mentioned in this
thread.
http://support.microsoft.com/kb/972397/EN-US
More Info says you also need http://support.microsoft.com/kb/983280
Phil W
-Original Message-
From: CristianG [mailto:cristian.gherghine...@gmail.com]
I think the sample VBScripts in the SDK are useful to the extent that they
describe the flow for folks that aren't familiar with how to use the APIs.
Exporting an MSI table with no guidance at all is a pain, but I can see from
WiExport.vbs that I open the database, do an OpenView with a Select
. Sadly I've seen far too many
people treat them as production libraries in their solutions.
From: Wilson, Phil phil.wil...@invensys.com
Sent: Tuesday, January 03, 2012 4:44 PM
To: General discussion for Windows Installer XML toolset.
wix-users
I believe the issue is fixed in MSI 5.0. I've forgotten who told me but I think
it was somebody in Microsoft.
Phil W
-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Sent: Friday, December 30, 2011 4:13 AM
To: General discussion for Windows Installer XML
after installing the redistributable
version. This could be used to find it in the registry. But I would use
a better approach if possible.
Regards,
Helge
Am 12.12.2011 21:53, schrieb Wilson, Phil:
You need something like this, not a registry search.
http://blogs.msdn.com/b/astebner/archive
You need something like this, not a registry search.
http://blogs.msdn.com/b/astebner/archive/2010/05/05/10008146.aspx
Phil W
From: Helge Kruse [helge.kr...@gmx.net]
Sent: Sunday, December 11, 2011 11:11 AM
To: wix-users@lists.sourceforge.net
Subject:
If it's just the product's install state that's needed, I would have thought
that using an Msi API such as MsiQueryProductState (ProductCode) might be more
useful than just seeing if someshortcuts are there. If you really need to see
shortcuts that's just a programming task that involves
You cannot make a new MSI file with a new ProductCode, run it and expect that
it will just update your existing files. You've changed the ProductCode, making
it a completely different product so yes you get two entries in ARP.
The other replies cover this anyway, but if you go the major
The actual case-sensitive property name is SourceDir:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371857(v=vs.85).aspx
SOURCEDIR is likely to be something internal that you should not be using.
Phil Wilson
-Original Message-
From: Parkes, Kevin
It depends how you intend to do that launch. Launching installers from
installers is generally a bad thing. MSI setups can't launch other MSI setups
in any reasonable way; your hosting MSI may fail having installed the driver,
so what about rolling back or dealing with the driver already
MsiZap was basically a friendly front end for the the MSI CleanUp Utility
msicuu_.exe, or maybe it was the other way round. Either way, the Windows SDK
no longer ships a clean up utility and it's been retired. Any version you find
is going to be old and out of date with respect to later
Are you really specifying the entire path? It seems like you are not. There's
no reason for Windows to change a fully specified path, but if you specify just
a file name Windows will use the current directory and it obviously has no way
of knowing that you mean the ProgramFiles folder. It may
If it's an upgrade, you can just uninstall the old service and install it again
with your new name. Change the Component guid for the service component and
that just works. I don't know of anything that will just change the name that's
supported by MSI.
The ServiceControl stuff lets you say
Beware though because many people get the impression that permanent is a
project setting, and consequently they install the same file later with
permanent = fale and expect it to uninstall. Permanent means permanent on the
system, forever ref counted by MSI to stay there.
IMO a better
0SP
Email Disclaimer
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: 07 November 2011 17:58
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix or MSI bug ?
And most Windows Installer paths end with a \ too, in the path
And most Windows Installer paths end with a \ too, in the path properties.
Phil Wilson
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Monday, November 07, 2011 6:45 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users]
I have heard that there is an issue with VS 2010 merge modules where they
always install files to the Module Retargetable Folder instead of the intended
one. That may have something to do wth it. Other issues may occurr when
InstallUtilLib.dll is 32-bit and you attempt to use it on a 64-bit
There are potential issues with the general idea of saving and restoring. If
the file has an MSI file hash then the file you copy back won't match the
installed file, and that means a repair is likely to restore the one from the
MSI file.
It might be useful to describe what problem you're
You could write something to monitor or read the Application Event log. There
are MsiInstaller entries created when a product is installed (and I think one
for failure too). They seem to be event ID 1033, and there's a ProductCode,
result and ProductName in the entry.
Phil Wilson
You may need to look at the log more carefully. If the uninstall of the older
version failed it will roll back and reinstall, and that will leave you with
both products installed. That's the issue with RemoveExistingProducts -after-
InstallFinalize where it's outside the transacted part of the
Just wondering - are you getting a FileVersion value in any of the
MsiAssemblyName tables in any of these MSI files? I can't quite get my head
around it, but in-place updates of a GACed assembly will happen when
FileVersion is there, and if the GAC's location has moved then some parts of
The MSI SDK says a 32-bit package consists of only 32-bit components so
you're not really playing by those rules. There's also this:
http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx
If you have 32-bit and 64-bit
Two entries in Add/Remove Programs usually means you tried to upgrade a
per-system product with a per-user install, or vuice versa (all other things
being correct to do the upgrade). A verbose log will say something near the
FindRelatedProducts action.
Phil Wilson
-Original Message-
Some of those VC merge modules have a Property table with ALLUSERS=1, so that
will do it. If you're using a bootstrapper maybe you could run the VC9 redist
executable instead of using merge modules.
Phil Wilson
-Original Message-
From: Castro, Edwin G. (Hillsboro)
VBScript is pretty straightforward.
Dim installer = CreateObject(WindowsInstaller.Installer)
And then
Installer.InstallProduct (path to msi, property list etc)
for each one.
I suspect PowerShell has similar capabilities.
Phil Wilson
-Original Message-
From: McCain, Jon
During an installation there may be more than those two. New ones may be fired
up to host custom actions. I agree, it all sounds normal to me.
Phil Wilson
-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Sent: Tuesday, October 04, 2011 1:53 AM
To: General
Is there anything about that interop that lets you see the equivalent of
MsiViewGetError or MsiGetLastErrorRecord? There's typically more error info
available from those.
Phil Wilson
-Original Message-
From: Brian Lemke [mailto:brian.le...@apihealthcare.com]
Sent: Tuesday, October
Windows Installer will set the Modify and Creation dates of data files to be
identical when they're installed - is that what you're seeing? That's to
identify modified-after-installation files. Maybe sometimes that's a future
date.
Phil Wilson
-Original Message-
From: Christopher
That's a system key that MSI installs will just update. Without knowing exactly
what that snmpwalk thing is doing, I'd guess that it may be ignoring the
MSI-based installs in ...\Uninstall\{guid}. This might be deliberate because
you can enumerate the MSI-based products with MsiEnumProducts(),
/qb means that the user interface sequence isn't run, so make sure your search
(I think there'll be an AppSearch standard action) is in the Execute and UI
sequences.
Phil Wilson
-Original Message-
From: Marc Bauer [mailto:marc@gmx.net]
Sent: Thursday, September 08, 2011 2:15 PM
The problem appears to be that BinaryKey specification. As the docs say the
custom action will not be installed into a target directory. You're not
running it from your install directory - you're running it streamed out of the
MSI file's binary table into some temp folder. It's not a type 18.
ARPINSTALLLOCATION is a property that people set to make their install location
visible via supported MSI APIs. It doesn't get persisted into the uninstall
environment unless you persist it, and the same is true of CUSTOMDIR. What are
you trying to accomplish here?
Phil Wilson
ARPSYSTEMCOMPONENT is just a property you set in the property table of the MSI,
like any other property. There's no need for anything special to set it.
As I understand this property of MSI files, it will prevent the installation
from writing any registry entries for the MSI in Add/Remove
...and be aware that Permanent is a setting that gets propagated to the system.
It's not just a project setting. I mention this because I've come across people
who have a follow-up question that goes something like Now I've marked the
component as not permanent anymore, why isn't it getting
You'll need to post an entire MSI log of the issue and point out the file(s)
that you believe should get installed but are not.
Phil Wilson
-Original Message-
From: Kurt Jensen [mailto:kurt.jen...@us.ophiropt.com]
Sent: Thursday, August 18, 2011 7:53 AM
To: General discussion for
Spiricon.Source.Gevicam.UI.dll is not installed; there are a number of things
wrong here:
=
MSI (c) (CC:18) [10:47:26:095]: Disallowing installation of
component:{CA4F7916-B9A9-5D6E-BD7A-98EFFC15AAA3} since the same component with
higher versioned keyfile exists
MSI (s)
Working direcory is WkDir in the Shortcut table in the MSI file, and the
documentation specifically says that you can put %USERPROFILE% in there, so
maybe it just works the same way in WiX too.
Phil Wilson
-Original Message-
From: John Daintree [mailto:jo...@dyalog.com]
Sent:
The issue may be that a custom action running elevated during an install on a
UAC system means runs with the system account and that may not have the
required database permissions.
Phil Wilson
-Original Message-
From: Michael Osmond [mailto:mosm...@baytech.com.au]
Sent: Wednesday,
1 - 100 of 977 matches
Mail list logo
