Have you got an embedded UI handler? The log seems to be saying that you have,
and that Windows sent it a INSTALLMESSAGE_RMFILESINUSE message, and got an
error result, an invalid return value.
Phil Wilson
-Original Message-
From: Adriana Rodean [mailto:adrya1...@gmail.com]
Sent:
, is possible to run as admin but launch application as
standard user?
If yes, then I suppose we'll need to use MSIREALADMINDETECTION as what Sascha
pointed out. Then my further question is how to do that.
Thanks again.
From: Wilson, Phil phil.wil...@wonderware.com
Much Information).
Back to business. So basically the run-as-admin but launch app
as-standard-user isn't possible. Am I right?
Thanks.
From: Wilson, Phil phil.wil...@wonderware.com
To: General discussion for Windows Installer XML toolset.
wix-users
That seems to be INSTALLSTATE_NOTUSED, commented in msi.h as component
disabled, but that just begs the question of what not used or disabled
means, but maybe it makes sense if you know more about that component. Is the
component marked as transitive?
Phil Wilson
-Original Message-
..and a couple of things that don't make sense to me:
1. There are always likely to be cases (admin install, over the shoulder, group
policy) where somebody else is doing the install on behalf of a user. So what
seems odd to me is Brian's comment that the key is in the wrong place because
it's
what our QA
wanted is, run as admin but launch application as standard user. I'm not
sure if this is possible. Can you tell me if it's possible?
Also, what does GPO mean?
Thanks!
From: Wilson, Phil phil.wil...@wonderware.com
To: General discussion for Windows
Maintenance mode means that the product is already installed, as defined by the
ProductCode guid and the PackageCode guid.
Phil Wilson
-Original Message-
From: Amy Rosewater [mailto:arosewa...@spectrumhr.com]
Sent: Tuesday, December 15, 2009 9:18 AM
To: General discussion for Windows
this point or are there other
ways to go?
Regards
Daniel
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@wonderware.com]
Sent: den 10 december 2009 23:52
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Question on updating GAC assemblies
We do the same thing. +1 to Sascha's comments.
Phil Wilson
-Original Message-
From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com]
Sent: Thursday, December 10, 2009 7:16 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How Do I Verify Group
Something here on that:
http://blogs.msdn.com/astebner/archive/2008/08/10/8847259.aspx
and you should keep the assembly name values the same (so don't change the
strong name).
Phil Wilson
-Original Message-
From: DanR [mailto:daniel.roberts...@repab.se]
Sent: Thursday, December
All the CommonFilesFolder values in merge modules are by convention appended
with a mangled guid, but as far as I can tell the mechanism that rationalizes
all the folder name properties from merge modules (such as
CommonFilesFolder.guid) at merge time is indiscriminate. If the folder name
from
You have OnlyDetect set to Yes when you detect the older version, that won't
cause the upgrade to occur.
Phil Wilson
-Original Message-
From: Giora keinan [mailto:grkei...@gmail.com]
Sent: Monday, December 07, 2009 1:35 AM
To: General discussion for Windows Installer XML toolset.
This is the MsiServiceConfig table in MSI 5.0 (Windows 7), and I think I've
read that WiX supports MSI 5.0. I don't know of any custom action support, but
it might be in the WiX extensions.
Phil Wilson
-Original Message-
From: Igor Paniushkin [mailto:ipaniush...@sdl.com]
Sent:
If you mean certificate signed, Windows is going to try to verify the signature
by going to the internet to validate it. This may be something to do with the
error. Where is the CA sequenced?
Phil Wilson
-Original Message-
From: Ranganatha H C [mailto:ranganatha...@gmail.com]
Sent:
This might help, added to .NET 3.0 FW install and hopefully still in 3.5.
http://blogs.msdn.com/astebner/archive/2006/08/30/731057.aspx
Phil Wilson
-Original Message-
From: Igor Lemsky [mailto:igor.lem...@gmail.com]
Sent: Wednesday, December 02, 2009 7:11 PM
To: General discussion
This sounds like a custom action that's being called, perhaps based on the
component's action state being to-be-installed. It's more likely that the
solution is to do something like amend the condition on the custom action to
include and Not Installed so that it doesn't run during a repair when
Because Windows doesn't preserve the values of those properties anywhere -
that's up to you. Typically people save them in the registry and retrieve them
with an AppSearch.
Phil Wilson
-Original Message-
From: cce91 [mailto:ell...@nortel.com]
Sent: Monday, November 23, 2009 1:55 PM
My suspicion is that you're right, and I think that's the area where each
assembly is recorded together with info for MsiProvideAssembly(), and it won't
be there if it's not the keypath.
Phil Wilson
-Original Message-
From: Andreas Mertens [mailto:andre...@nvisionideas.com]
Sent:
Not easily, no, and not from the MSI uninstall dialog. It's a standard
FilesInUse dialog, and I think that Windows will show its own even if you don't
have one in your MSI file. Why is this an issue anyway? Do you want it done
automatically? The alternative might be a reboot to clean up the
I'll top that off with Heath's article...
https://blogs.msdn.com/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx
Phil Wilson
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Thursday, November 12, 2009 8:51 PM
To:
Somebody mentioned this before I think, but maybe InstallShield's project files
are still in an incomprehensible format. This means that if you use a source
control tool then the ability to see the difference between one version and
another is impossible. Can you imagine a development
and Guid's, WiX simply
rocks at handling it.
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves
attention? E-Mail Me
--- On Fri, 11/13/09, Wilson, Phil phil.wil...@wonderware.com wrote:
From: Wilson, Phil phil.wil
I understand that there's the idea that if you ship code that uses VC++ version
x then just use that merge module, forget policy files, your app will work, but
then again if the redist does install policy files there is no consistent rule.
The policy files redirect older versions of the Dlls
This should help:
http://wix.mindcapers.com/wiki/Shortcuts_in_WiX#What_are_Advertised_Shortcuts.3F
Phil Wilson
-Original Message-
From: JK E-Lists [mailto:jkli...@ifm-services.com]
Sent: Wednesday, November 11, 2009 11:08 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users]
A couple of comments:
1. It's only since UAC that the per-machine/per-user difficulty has been
around. It's not been there forever. MSIINSTALLPERUSER is the solution in MSI
5.0.
a elevated perUSer
installation: InstallScope=perUser actually does override a manually coded
InstallPrivileges=elevated attribute! So is that a bug in WiX?
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@wonderware.com]
Sent: Donnerstag, 5. November 2009 21:44
To: General discussion
Sascha's point is that you can save this yourself if you really want to get it
from the registry. ProductID might be the better property to change because
it's been through any verification that might be done by ValidateProductID.
However if you've already shipped the original it's too late,
Anweshi
From: Wilson, Phil phil.wil...@wonderware.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Mon, November 2, 2009 10:56:18 PM
Subject: Re: [WiX-users] How to change the installation to point to C:\
What's
It might be set in the registry (isn't everything?) but that seems to be an
implementation detail. AFAIK the correct way to get this value for an installed
product is to call MsiGetProductInfo(product code guid, ) passing
ProductID as the property name.
Phil Wilson
-Original
What's special about the C: drive? Maybe you need the ROOTDRIVE or
WindowsVolume property.
Phil Wilson
-Original Message-
From: Anu Dev [mailto:queryl...@yahoo.com]
Sent: Monday, November 02, 2009 6:49 AM
To: WIX
Subject: [WiX-users] How to change the installation to point to C:\
Hi
The WScript.Echo won't work - that's supplied by the WSH object, not by MSI. Do
you see that message?
MsiProvideComponent is normal - any of the entrypoints that have a Darwin
descriptor (COM,file associations, shortcuts) use that to locate the target
file (causing repair if needed).
Apart
One more note - IIRC MSI's advertised shortcuts aren't drop targets and don't
show up in the SendTo context menu even when they're in the SendTo folder.
You'll need a non advertised shortcut.
Phil Wilson
-Original Message-
From: Evan Beeton [mailto:ebee...@informasoftware.com]
I know DTF has some support for external UI, but once you have your own forms,
and you've called (Msi)SetExternalUI(Record), why not just call
MsiInstallProduct with the command line properties you want to set?
Phil Wilson
-Original Message-
From: Rob Mensching
Just to point out that vital doesn't mean install this file whatever else
happens. There are still component rules etc that take precedence.
http://msdn.microsoft.com/en-us/library/aa368596(VS.85).aspx and
msidbFileAttributesVital
Phil Wilson
-Original Message-
From: Sandeep
The StartType field in the resulting ServiceInstall table is DoubleInteger, so
a [property] isn't a legal value (it would require the field type to be
Formatted).
Phil Wilson
-Original Message-
From: eneo [mailto:e.karagj...@gmail.com]
Sent: Thursday, October 29, 2009 11:51 AM
To:
I think you might as well create your own custom table, then you would return
all the entries as well as define other information in the table (description,
how to install etc).
Phil Wilson
-Original Message-
From: Dominique Louis [mailto:dominique.lo...@amxeurope.com]
Sent:
If updatable installation is referring to the fact that you'll be doing a
major upgrade with Upgrade elements, why do you need this? An upgrade is a new
install that users can install to whatever path they want. It so happens that
an upgrade can also remove prior versions, but it seems unusual
2753 is nothing directly related to FilesInUse - look up the Windows SDK
Windows Installer errors for this kind of thing.
It's typically caused by running a custom action referring to a program that is
not going to be installed. So it looks like you're asking to run MainApp but
the one in
3.0.4805.0.
If you have any idea, please let me know.
Thanks a lot.
/Brian
From: Wilson, Phil phil.wil...@wonderware.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Friday, October 2, 2009 1:57:16 PM
Subject
argument. Is
this the problem?
So one thing worth noticing, if there is no old version running, everything is
fine. I'm really puzzled.
Thanks again, Phil.
/Brian
From: Wilson, Phil phil.wil...@wonderware.com
To: General discussion for Windows Installer XML
For UAC, deferred is the right thing to do, and running without impersonation
is also the right answer. Unless you have arranged to run the entire MSI
install elevated, running impersonated as Administrator really means ...but
with a limited user token, and immediate custom actions won't be
Keep in mind that the sufficient privileges message is a generic one that it
pops out whenever something goes wrong with a service. The error number is
more useful, but you didn't report it. There's some differentiation between the
error being an install error, a start error, stop error etc.
I frequently lose track of all this, but I think (well for today at least):
1) You can't trust Privileged when there is going to be an elevation prompt in
the execute sequence. The UI sequence can be untrustworthy. If you want older
semantics, set the MSIUSEREALADMINDETECTION property to get
Generally speaking, if people want that degree of control over the result they
don't use a pre-existing program because this is the kind of frustration they
run into. I've run into this type of ping problem before, and found a C++
example on the internet. So in this case I'd be sticking that
As far as I can tell, what you have there is a component declaration with a
condition about whether it should be installed or not.
However the issue seems to be that the custom action ' SchedXmlFile' is being
called, so what matters is the condition you have on that custom action call,
in
There's a topic here about preventing patch access to the original source:
http://msdn.microsoft.com/en-us/library/aa370841(VS.85).aspx
Phil Wilson
-Original Message-
From: Tony Juricic [mailto:tjuri...@tradestation.com]
Sent: Thursday, September 17, 2009 11:08 AM
To: General
This the kind of thing that depends on your customers. Sometimes too much
choice is a bad thing. If I installed a new product and it said do you want to
start some service? my reaction would be how the hell would I know and why
should I care? Just start the darn thing! It's potentially up
I've seen some comments suggesting that file costing gets slower when the
current TARGETDIR is populated, and if that's the case it presumably makes the
costing calculations more complex The same might be true if other target
folders are populated (and that's more speculation). Nevertheless,
I've not come across the Vista scripting issue that Blair mentioned, but AV
programs are always looking for scripts that might be dangerous. In some cases
I believe they even intercept calls to the scripting engines. This is typically
the reason so many setups ask you to disable AV programs
I'll just add (and risk stating the obvious) that if a limited user could
actually perform an install that changed areas on the system that are
restricted to administrators, then that would be one heck of a security hole.
Administrator credentials have to be supplied somewhere, whether it's an
It's also required in a few cases. For example, the ServiceInstall table in an
MSI file defines a component, not a file name, and the KeyPath of that
component must be the service executable file. Type libraries have a similar
requirement if the registration uses the TypeLib table. I'm not
If you have multiple Upgrade entries for all the UpgradeCode values you want to
upgrade that should work fine and uninstall them all. There's no rule that
says an upgrade must upgrade only one installed product.
Phil Wilson
-Original Message-
From: MYFLEX
I've seen this when it's not an installer issue, it's because the .NET binaries
are AnyCpu and consequently run as native 64-bit and can't load 32-bit
dependent Dlls. When this happens during the install custom actions fail etc.
You didn't see any kind of error message when the install failed?
There's no connection between the property you put in your Upgrade entries and
what actually happens. I'm really very sure that OLDAPPFOUND is for your
information only - it doesn't drive anything, so changing it won't affect
anything.
What you need to arrange is as previously suggested, have
So it looks like Amy's multiple products all have the same UpgradeCode,
different ProductCodes.
If they also all have the same ProductVersion then there's no way to
distinguish one from another in the Upgrade table. The kind of thing needed is
either:
a) Multiple upgrade codes for the
In the custom action code session[PIDKEY] is null.
Why the quotes around PIDKEY?
Phil Wilson
-Original Message-
From: Oscar Newkerk [mailto:osc...@unifysquare.com]
Sent: Tuesday, September 01, 2009 8:54 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re:
I read that to mean that the component is already installed and doesn't need
updating from your new setup, perhaps because the versions are identical. Your
RemoveExistingProducts is probably sequenced to run at the end of your install,
so it's applying update rules. In some cases you might see
That something is the Property table in those merge modules has a setting for
ALLUSERS=1.
Perhaps you could add a hidden feature and put all those merge modules into it.
Then use the Condition/Feature (the Condition table) to set the level to not
install them if ALLUSERS1.
Phil Wilson
You haven't said this in any of your posts, but if this is associated with
error 1324 then there are several articles in MS HelpSupport about this
message, such as:
http://support.microsoft.com/kb/923101
or
http://support.microsoft.com/kb/894510
which is about the Shell Folders registry
It's too late if you've already shipped that product, but for future reference
if you have an uninstall custom action that you do NOT want to run during an
upgrade add the condition NOT UPGRADINGPRODUCTCODE. That property is set in
the old product being uninstalled during an upgrade.
Phil
There are plenty of .NET libraries out there. The worst ones use MSI.DLL as a
COM reference and it's often unreliable because those interfaces are basically
intended for late-binding using the installer's scripting model. The best ones
(like Richard's) are just C# source code with P/Invoke to
If the program is returning a non-zero exit code and your custom action type
isn't ignoring it then you'll see an error reported.
Phil Wilson
-Original Message-
From: Andrew Macvean [mailto:mad_man_...@hotmail.com]
Sent: Tuesday, August 11, 2009 5:18 AM
To:
I think you should get the upgrade working first before trying to get the CA
working. The CA seems to be dependent on the upgrade working anyway, and it's
not clear to me from your comments that the upgrade is working the way you
want.
A major upgrade will add new software to Add/Remove
I checked the updated merge modules with the kb article descriptions of file
versions. ATL90.DLL is 9.0.30729.4148, that seems to be the one, x86 and x64.
Phil Wilson
-Original Message-
From: Andreas Mertens [mailto:andre...@nvisionideas.com]
Sent: Friday, August 07, 2009 11:26 AM
TechNet reports this as normal:
http://technet.microsoft.com/en-us/library/cc774140(WS.10).aspx
Phil Wilson
-Original Message-
From: MacDiarmid, James D [mailto:james.macdiar...@eds.com]
Sent: Tuesday, August 04, 2009 8:31 AM
To: General discussion for Windows Installer XML toolset.
Those errors are all Access Denied, so this looks like something to do with how
the code is running. Deferred? Immediate? Impersonated?
Phil Wilson
-Original Message-
From: quattro004 [mailto:quattro...@gmail.com]
Sent: Monday, August 03, 2009 11:36 AM
To:
Just to expand, it's about sharing with non-MSI installs that use the Shared
Dll ref count registry mechanism. The only reason to set it is if you know
that there is a non-MSI install that installs the file to the same location and
increments the shared Dll counter. You don't need to set it if
The stock answer is to use MsiProcessMessage as described here:
http://msdn.microsoft.com/en-us/library/aa367525(VS.85).aspx
Phil Wilson
-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Monday, July 27, 2009 7:17 AM
To: General discussion
Because the Welcome dialog (to use that example) is the only entry you need on
a normal fresh install. It enters a UI sequence in which the Next and Previous
dialogs will be determined by the choices the user makes, and driven by
ControlEvent actions (like the NewDialog ControlEvent).
Phil
I'd check the MSI log in case Windows 7 has changed behavior. If the
screensaver is hooked into Explorer in some way Windows might decide to
postpone the file removal until a reboot. There are other sharing scenarios
that will also have this effect (like saying the component is shared and
the old
component guid.
So instead I'm checking for the presence of this file. If it's there, I want
to fail the install.
-- Forwarded message --
From: Wilson, Phil phil.wil...@wonderware.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Date
What's the goal here? Are you looking for that file, or is it just a marker for
a previous version of the product? If it was previously installed with an MSI
package a component search would be more reliable - it doesn't depend on
directory locations, and it works if the user changes the
I don't know that they do! How do you automate that a developer says this file
should be installed to that location? There's no way to automate that unless
you have some tool that records it, and that tool is basically WiX. You could
have another pretty GUI tool that records what developers
This can be made to happen automatically if the files are keypath files, or the
keypath for the file's component is a HKCU entry - use of one of the MSI
advertised entries (shortcut, COM activation, file association) will cause
Windows to do that MsiProvideComponent on the user's behalf. I
Assuming you mean uninstall still, a custom action that calls MsiProcessMessage
with INSTALLMESSAGE_COMMONDATA as documented here will do that:
http://msdn.microsoft.com/en-us/library/aa370354(VS.85).aspx
Do it as early as you can in the InstallExecute sequence. When I've done this
it's not a
I guess the issue here is the expectation that the MSI property called
ProductVersion should behave the same was as an individual version in a file
resource? Even though they're used for different purposes? I feel a Raymond
Chen moment coming on. MIDL version is just 2 digits (and
We also ran into this problem. It is just stupid that visual studio projects
use 4 part version numbers and MSI only supports 3.
Visual Studio doesn't. We're talking in the context of major upgrades and the
ProductVersion property. In Visual Studio that's the Version property of the
Setup
Are you actually launching msiexec.exe? The one in the SysWow64 folder rather
than the 64-bit one?
Phil Wilson
-Original Message-
From: Michael Ballou [mailto:mbal...@eeye.com]
Sent: Monday, July 13, 2009 2:47 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] 32-bit app
Given that the name of this Dll is BuildShell64.dll, you're not by any chance
trying to register a 64-bit Dll on a 32-bit system are you? Or using a 32-bit
regsvr32 on a 64-bit system to register a 64-bit Dll?
Phil Wilson
-Original Message-
From: Eswari [mailto:sravi...@yahoo.com]
Did you look at MsiGetFeatureCost?
Phil Wilson
-Original Message-
From: Andy Glass [mailto:agl...@laserfiche.com]
Sent: Monday, July 06, 2009 9:06 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] (no subject)
I'm writing a bootstrapper that will include multiple MSI
That's correct - they're uncomfortably like some C /C++ types, to use that as
an approximate analogy. People trip over this sometimes with the standard
properties. For example the Installed property isn't set to true or false. It's
a string which (IIRC) is a date.
Phil Wilson
-Original
I don't think it has to be complicated. Typical is the feature set that most
users will use all of the time. Complete is everything, all the features.
Without details it's hard to say, but Typical might exclude tutorials, samples,
templates, migration tools etc that aren't need to run the app.
CryptProtectData () has a CRYPTPROTECT_LOCAL_MACHINE flag. If the
CRYPTPROTECT_LOCAL_MACHINE flag is set when the data is encrypted, any user on
the computer where the encryption was done can decrypt the data.
Phil Wilson
-Original Message-
From: Peter Shirtcliffe
It's 0x80110424 = The file does not exist.
Phil Wilson
-Original Message-
From: MacDiarmid, James D [mailto:james.macdiar...@eds.com]
Sent: Wednesday, June 24, 2009 10:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Getting Error Code -2146368476
Execute=Immediate is before any files are installed. It needs to be deferred.
Phil Wilson
-Original Message-
From: little.forest [mailto:little.for...@ymail.com]
Sent: Wednesday, June 24, 2009 10:22 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users]
?Componentname=3 might work, installed state of the component.
http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx
Phil Wilson
-Original Message-
From: dangle...@hotmail.com [mailto:dangle...@hotmail.com]
Sent: Wednesday, June 24, 2009 12:05 AM
To: General discussion
: Local; Action: Local
MSI (s) (40:44) [15:25:16:531]: Component: XTimers; Installed: Absent;
Request: Local; Action: Local
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@wonderware.com]
Sent: Wednesday, June 24, 2009 1:29 PM
To: General discussion for Windows Installer
Windows Installer supports a MaskedEdit control that you can put in your WiX
source. The associated mask will be some number of # characters.
http://msdn.microsoft.com/en-us/library/aa369797(VS.85).aspx
Phil Wilson
-Original Message-
From: Hukumchand Shah
Running without impersonation means you're running with the SYSTEM account.
This has no network access rights, and results in presenting some variations of
Anonymous or the machine account to other systems depending on the AD or trust
configuration.
Phil
Not in my experience. My consistent observation is that the more code (custom
actions) there is in the install the more likely it is to fail. If your
complex means lots of custom actions then prepare for extra difficulty!
This is not a reflection on WiX custom actions, but sequencing them and
I have a solution to propose, but first a comment.
It's ok for a customer to have requirements and needs. The issue here is that
maybe the customer and your manager decided what the solution was going to be.
I don't know if that's the case, but if your manager and the customer cooked up
some
If you're doing a recursive MSI install it's not going to work. That's why
there are bootstrappers and chainers that install MSI-based setups sequentially.
Phil
From: Robert Hermann [rob.herm...@nicewareintl.com]
Sent: Tuesday, June 16, 2009 6:10 AM
To:
Do these binaries have a version?
Phil Wilson
-Original Message-
From: varun kataria [mailto:varunk0...@yahoo.com]
Sent: Monday, June 15, 2009 2:33 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Inconsistent modification date time of Patched
The short answer is that you call MsiInstallProduct and when it returns you're
finished. Does that mean you're not doing this?
Phil Wilson
-Original Message-
From: Tomasz Grobelny [mailto:tom...@grobelny.oswiecenia.net]
Sent: Thursday, June 11, 2009 9:05 AM
To: General discussion for
@lists.sourceforge.net
Subject: WiX-users Digest, Vol 37, Issue 54
--
Message: 2
Date: Tue, 9 Jun 2009 12:45:41 -0700
From: Wilson, Phil phil.wil...@wonderware.com
Subject: Re: [WiX-users] Action Execute Sequence in merge module
To: General discussion for Windows Installer XML
Unless you know for sure that aspnet_regiis.exe will return a zero exit code
you should change your custom action type to ignore exit code.
Phil Wilson
-Original Message-
From: Shree Krishnamurthi [mailto:shree.krishnamur...@proximex.com]
Sent: Wednesday, June 10, 2009 2:10 PM
To:
?ComponentName=3 is about if the component is already installed. I suspect you
need $ComponentName=3, meaning that the component is marked to be installed.
Phil Wilson
-Original Message-
From: Shree Krishnamurthi [mailto:shree.krishnamur...@proximex.com]
Sent: Tuesday, June 09, 2009
There's no reason for Windows to do this unless you are doing something with
services that's causing this. Do you have anything in your ServiceControl
entries? Any uninstall custom actions that might be doing this?
Phil Wilson
-Original Message-
From: rahul.ekb...@sungard.com
An MSI install is an MSI install, whether it was built by WiX or something
else. You can still do a major upgrade to remove the older products.
Using the SCM to uninstall the services is just a bad idea. Uninstalling the
services won't uninstall the owning product, so you're still going to see
Safest default for files is to just set keypath to yes and have one file per
component. Sometimes it's required. For example, the ServiceInstall table in
an MSI file doesn't name a service - it names a component, and the keypath of
that component is expected to be the service executable. The
401 - 500 of 977 matches
Mail list logo
