I think you're on the right track there.
Thelogwill sayif the file is really being installed. I'm
wondering if there's an existing version of the file out there.The message
might be something to do with the file not being installed because it's already
there with the same version (or
Stdole2.tlb has been part of the OS for a while (since at least Windows
2000), and it's in the list of protected files since then so you
wouldn't be able to replace it anyway. I'd be surprised if you really
need to install it.
Phil Wilson
-Original Message-
From: [EMAIL PROTECTED]
This looks useful:
http://support.microsoft.com/kb/164539/
Phil Wilson
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob
ArnsonSent: Wednesday, September 06, 2006 11:22 AMTo:
Vitaliy IlyinCc: wix-users@lists.sourceforge.netSubject:
Re: [WiX-users] IE version in condition
That's the whole point really. The general issue is
that many custom actions are arguably incorrect because to access secure parts
of the system theyrun with the installing user's privilege, who was
therefore required to be privileged. The "right" thing is to run deferred with
Verify that the SYSTEM account is allowed access?
Should be Full Control, I believe.
Phil Wilson
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of dangle123
...Sent: Thursday, September 07, 2006 1:15 PMTo:
wix-users@lists.sourceforge.netSubject: [WiX-users] Error 1303. The
It knows all your paths because given a ProductCode and a component guid
it can use things like MsiGetComponentPath to find them. it knows all
your properties is too general to reply to, but it certainly doesn't
persist the values of properties that you create during your first
install (unless
The standard way to persist that (the main application directory) is
to use a type 51 custom action and set the ARPINSTALLLOCATION property,
then it will get persisted in the MSI way (meaning that
MsiGetProductInfo with INSTALLPROPERTY_INSTALLLOCATION and other
standard APIs can get it).
Phil
What about version specs in your Wix UpgradeVersionElement? I don't know
how Wix behaves in the absence of them, but there's nothing in your Wix
that targets the versions you want to upgrade.
Phil Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
: Friday, September 22, 2006 11:15 AM
To: Wilson, Phil; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Quick question on upgrade checking
What version specs do you refer too?
Here is the WXS:
Upgrade Id=snip
UpgradeVersion RemoveFeatures=All Property=UPGRADE
IgnoreRemoveFailure=yes
That needs the FileVersion Name-Value pair to be in the
MsiAssemblyName data, and to state the obvious the file version must be higher
than the existing version in the GAC.
Phil Wilson
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Frank
TseSent: Friday, September 22,
Both old and new are installed for the same users? (Both per-system or
both per-user).
Phil Wilson
-Original Message-
From: Jeff MacDuff [mailto:[EMAIL PROTECTED]
Sent: Friday, September 22, 2006 1:31 PM
To: Jeff MacDuff; Wilson, Phil; wix-users@lists.sourceforge.net
Subject: RE
PROTECTED]
Sent: Friday, September 22, 2006 3:16 PM
To: Wilson, Phil; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Quick question on upgrade checking
Yes, it's installed for all users.
-Original Message-
From: Wilson, Phil [mailto:[EMAIL PROTECTED]
Sent: Friday, September 22
ersion can be used for in place update.
Phil Wilson
From: Mike Dimmick
[mailto:[EMAIL PROTECTED] Sent: Saturday, September 23,
2006 8:08 AMTo: Wilson, Phil; Frank Tse;
wix-users@lists.sourceforge.netSubject: RE: [WiX-users] how to
enforce assembly to be gac'd even when thereisalready a copy i
In C++, I think I'd start with the path functions. If
you have a path from the browse for the installation folder,
PathGetDriveNumber will return a number from 0 to 25 corresponding to A: through
Z:
I did a quick test - include shlwapi.h and link to shlwapi.lib, and
PathGetDriveNumber
versions
Wilson, Phil wrote:
The standard way to persist that (the main application directory) is
to use a type 51 custom action and set the ARPINSTALLLOCATION
property, then it will get persisted in the MSI way (meaning that
MsiGetProductInfo with INSTALLPROPERTY_INSTALLLOCATION and other
is INSTALLUILEVEL_FULL (or completely interactive).
--
InstallExecuteSequence
Custom Action='LaunchReadme' OnExit='success'
(NOT Installed) AND (UILevel=5)
/Custom
/InstallExecuteSequence
John
Wintellect - Know How
http://www.wintellect.com
877-968-5528
From: Wilson, Phil [EMAIL
There's a vbscript WiGenXfm.vbs in the Windows Installer SDK.
Phil Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alexander
Gnauck
Sent: Monday, October 09, 2006 1:45 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] create
defaults to
assembly version in the absence of AssemblyFileVersion.
Phil Wilson
From: Bob Arnson [mailto:[EMAIL PROTECTED]
Sent: Monday, October 09, 2006 8:20 PMTo: Frank
TseCc: 'Mike Dimmick'; Wilson, Phil;
wix-users@lists.sourceforge.netSubject: Re: [WiX-users] how to
enforce assembly
Properties are case-sensitive in that syntax you're using. Try ALL.
Phil Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dane
Anderson
Sent: Monday, October 16, 2006 9:28 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Uninstall
=3490Remove=all/Custom
and
Custom Action=DeleteCabs Sequence=3490REMOVE=All/Custom
and
Custom Action=DeleteCabs Sequence=3490Remove=All/Custom
With all I got the same results. It doesn't execute the DeleteCabs
CustomAction.
-Original Message-
From: Wilson, Phil [mailto:[EMAIL PROTECTED
Some thoughts:
Those non-MSI uninstallers often have a quiet switch, so if there's no
need to show the uninstall UI append that to the uninstall string. I
know the InstallShield one does, I'd expect the Wise equivalent to have
the same.
I don't think it's a good idea to have the uninstall
back.
Phil Wilson
-Original Message-
From: Arnette, Bill [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 18, 2006 2:36 PM
To: Wilson, Phil; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Install with prevous versions
So your recommendation is to run the uninstaller
CTED] Sent: Thursday, October 19, 2006
11:02 AMTo: Wilson, Phil; Wix-user mailingListSubject: RE:
Re: [WiX-users] Fw: Uninstall a cached msi
Yeah,
and I would never recommend people going into an undocumented data store and
start tweaking stuff they find there.
From:
[EMAIL PROTECTED]
[mai
But if you're calling it from a custom action, aren't you detecting a
FilesInUse condition that the standard one did not detect? I'm not why
you'd call it from a CA if MSI is showing FilesInUse when necessary.
Phil Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
A malformed guid is the easiest way. If you're p/invoking there are
going to be other opportunities to get the buffer passing wrong.
Phil Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter G.
Sakhno
Sent: Friday, October 20, 2006 11:49 AM
It's not the file time. It's basically the same as the MSDN topic about
file versioning with/without file hash:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/set
up/neither_file_has_a_version.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/set
I'm not as Wix-savvy as I should be (a cop-out that I don't know the
syntax you need) but it seems to me that you just need to specify that
your executable is in [TARGETDIR] (which is probably where you installed
it, right?). You want to be running the program at
[TARGETDIR]SQLite3.exe.
Phil
Just set it up to remove any version at all, 0 - 65535
for example. Typically people just want to upgrade older versions and prevent
uninstall of newer versions, so that's mostly what you see, but you can remove
what you like.
Phil Wilson
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
If you have a .NET assembly exposing COM interfaces you don't need an
interop Dll, but you need it registering in the same general way that
Regasm does (there's Tallow). Gacutil just puts it in the GAC. What you
get for a registered .NET assembly are CLSID/{Guid} entries that show
mscoree.dll as
Maybe I'm misunderstanding here, but I was assuming you had managed
code. It sounds like you have a conventional C++ COM Dll, so it's just
the Win32 COM DllRegisterServer variety of registration, using Wix
registry entries for class, interface, ProgId and type library
registration. What's
Does the error description make any sense in your context?
/// When installing multi-file assemblies into the GAC, the hash of each
module is
/// checked against the hash of that file stored in the manifest. If the
/// hash of one of the files in the multi-file assembly does not match
what is
I believe this is the "official" registry key for
SP1:
http://blogs.msdn.com/astebner/archive/2004/09/14/229574.aspx
I suspect an MSI file search is somewhat easier. A
search for mscorlib.dll in
[WindowsFolder]Microsoft.NET\Framework\v1.1.4322with a MinVersion of
1.1.4322.2299 (1.1SP1
Also, one of the restrictions on svchost.exe is that
you can't name it as an authorized application to get through the Windows
firewall,just to give you a heads up in case you might want to do that.
Phil Wilson
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike
That could not find part of the path message is sometimes security
related. So if you're impersonating a limited user you can't update
files in the Program Files folder.
Phil Wilson
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dana
Gutride
The file [2][3] is being held in use by the following process: Name:
[4], Id: [5], Window Title: '[6]'.
The first problem: what the HECK are 2, 3, 4, 5, and 6?
It's a template, actual values supplied at run time.
That log seems to show that your KioskKillerMain call failed, an error
was
I believe you're back in the non-elevated part of the installation
because by default you can't be elevated unless you run as a deferred
CA, and you can't be deferred outside the InstallInitialize/Finalize
actions. It's an immediate CA, right?
Phil Wilson
-Original Message-
From:
You need a type 51 custom action that sets ARPINSTALLLOCATION.
Phil Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John Brown
Sent: Monday, November 27, 2006 11:16 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] InstallLocation
Jumping in late here
It's not at all clear to me that a reboot is supposed to be asked for in
these situations, even though the log will have text about a reboot
being necessary. I honestly don't recall reboot requests out of
uninstalls except when they were explicitly added. This is what I
A guess: most likely the UI is setting a property that's used as a
condition on the component, let's assume it's the component that
installs the service and starts it. If the value of the property is not
preserved but is used again as a condition on uninstall the service
won't uninstall because
Just to add that if one wanted to see a consolidated list of how the
bootstrapper manifest checks and installs products (and this includes
SQL and J# 2.0), build a Visual Studio 2005 SetupDeployment project
bootstrapper with all the prerequisites checked. This builds an exe with
the manifest in
You mean you want the download for Windows Installer, SQL Express, .NET
Framework, J# etc to be all in one file? Just trying to understand.
Phil Wilson
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David
Thielen
Sent: Wednesday,
David Thielen
www.windwardreports.com
303-499-2544 x1185
Cubicle Wars - http://www.windwardreports.com/film.htm
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Wilson,
Phil
Sent: Wednesday, December 06, 2006 2:06 PM
To: wix-users
Turn on the Windows Installer logging policy for the uninstall and take
a look at the log produced in the temp folder. The in-use logging is in
the InstallValidate action.
http://support.microsoft.com/kb/223300
I'd add x to the list of logging options - voicewarmupx
Phil Wilson
My inclination would be to do a major upgrade each time, sequencing
RemoveExistingProducts to uninstall the old app first then install the
updated one.
The issue with REINSTALLMODE is that it applies to every file in the
product, and I'm assuming you don't want to use (say)
REINSTALLMODE=vamus
This is the versioning description:
http://msdn2.microsoft.com/en-us/library/aa368267.aspx
It might not explicitly say so, but MSI sets the creation/modify dates
to be identical when unversioned files are installed, the reason being
that if these dates are later found to be different then the
If you want this assembly registered for COM interop the /tlb option by
itself is insufficient. Using full regasm on an assembly does two main
things:
1. Registers the class entries and sets the InprocServer32 to
mscoree.dll.
2. Registers a type library.
Just using the /tlb option does not do
Advertised shortcuts are more common that you imagine, and more normal too.
Anytime you look at the properties of a shortcut and the Target is greyed out,
it'll be an advertised shortcut (differentiating from advertised features).
Every Office 2003 shortcut looks like that, so clearly a LOT of
I'll start by saying that I dislike the term advertised in this
situation, just like I dislike it in the context of COM registration
from the Class table in the MSI file. The context here is resilience.
There are descriptors in shortcuts (and COM registration from the Class
table) that basically
FWIW, the RegSpy utility here
http://www.installsite.org/pages/en/tt_analyze.htm (scroll down to
RegSpy) can monitor registration of out of process servers. It initiates
the process suspended with the /regserver command line, then injects
code to call RegOverridePredefKey for the process, then
I can't tell what's actually going on with those versions either.
Changing file versions is a requirement for a minor upgrade to be
useful, so I wonder what Aaron did. You're supposed to update versions
of files that have changed, build an MSI file with a new PackageCode but
the same ProductCode
This looks like Aaron's problem:
http://blogs.msdn.com/windows_installer_team/archive/2005/08/17/451516.a
spx
A feature will be marked as advertised if you removed any components.
Phil Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob
Do you care which one? VS 2003 and 2005 are both devenv.exe and could
both be running.
I'm also curious why you care - this might be one of those cases where
describing what you want to achieve is more useful than asking how to
implement your solution.
Phil Wilson
The Windows Installer version might be too old on that system. It's 3.0
you need.
Phil Wilson
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Emma Hanna
Sent: Wednesday, January 10, 2007 4:43 PM
To: wix-users@lists.sourceforge.net
Subject:
Does it does not allow me to install mean that it doesn't start the
MSI setup at all, or that it fails at some point, and if so, what's the
error? Are you using custom actions?
And my application requires these privileges isn't anything to do with
the installation, unless you're assuming that
Windows Installer has a WindowsVolume property too.
Phil Wilson
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Levi
Wilson
Sent: Thursday, January 11, 2007 9:45 AM
To: Eric Fesh; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Another
Services have always been run in Session 0. I suspect you're thinking
about Vista where services still run in Session 0 but apps run in other
sessions. AFAIK this behavior doesn't change just because the account
changes.
Phil Wilson
From: [EMAIL PROTECTED]
If this is the only Service in the setup, then I suppose you could add a
condition to the ServiceInstall standard action. Install the file
always, condition ServiceInstall on your condition, and there's more
complication with remembering to do the uninstall of the Service, and
conditions on the
Deferred also means it needs to be before InstallFinalize. Did you get error
2762?
Phil Wilson
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of André Schoorl
Sent: Friday, January 12, 2007 5:03 PM
To: wix-users@lists.sourceforge.net
Subject:
The other question to ask is whether this really belongs in the
installation at all. The line between installation and configuration is
sometimes a huge gray area, but this could be seen as application
configuration that doesn't need to be in the installation.
I've heard suggestion that where
The recipe for a minor upgrade by reinstalling the product is to rebuild
the MSI file with the higher versioned code files, change its
PackageCode, increment its ProductVersion, and install with msiexec /I
new msi file REINSTALL=ALL REINSTALLMODE=vomus. If you broke the rule
don't delete a
Immediate custom actions don't have access to installed files, unless
they're after InstallFinalize, and with that deferred one you just need
to set the Wix magic that says don't wait - that's why the MSI is
waiting for it to complete.
Phil Wilson
From:
There isn't really a good way to do this. It's not a Wix thing, it's the
fact that a shortcut is part of a component, so when a component gets
installed the shortcut gets installed, just like everything else in the
component does.
Phil Wilson
-Original Message-
From: [EMAIL PROTECTED]
It's described here as an upcoming KB article for a known issue,
although I haven't found the actual article.
http://blogs.msdn.com/windows_installer_team/archive/2006/10/30/preview-
of-upcoming-kb-articles-windows-installer-4-0-on-windows-vista.aspx
Phil Wilson
This might be just MSI behavior, which is to create that random MSI file
name in the temp folder and use that for the install. If you monitor the
temp folder I suspect you'd see that random MSI file name there, and I
believe it's what gets copied to the cached location in
Windows\installer.
Phil
Even when you get all the Wix/MSI stuff right, a common issue is that
the account doesn't have the log on as a service right.
Phil Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Victor
Sergienko
Sent: Wednesday, January 24, 2007 2:36 PM
To:
great. It seems like a good portion of the book is
spent talking about what the Visual Studio generated installers can't do
and how to get around it.
Jeff Bean
Wilson, Phil wrote:
This might be just MSI behavior, which is to create that random MSI
file name in the temp folder and use
Use a Type 19 custom action instead, then you get a messagebox with your
text in it and the uninstall just exits.
Phil Wilson
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John
Lalande
Sent: Friday, January 26, 2007 10:22 AM
To: Bob Arnson
Cc:
Assuming for the sake of argument that Wix uses the IReferenceIdentity
interface, is there actually a mismatch occurring? The point I'm making
here is that it's normal for the 32-bit-only assemblies to go to GAC_32
and the portable ones to GAC_MSIL, depending on how they were built.
Phil Wilson
that installs some COM components. I have a CA
that needs to use one of these COM objects, so I added it to the
InstallExecute sequence after RegisterProduct.
[Wilson, Phil] There is no so here. RegisterProduct is not significant
as a marker for whether COM components have been registered yet or
become
The condition to use for an uninstall is REMOVE=ALL, it's true on an
uninstall.
Phil Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joseph
O'Sullivan
Sent: Tuesday, February 06, 2007 1:48 AM
To: wix-users@lists.sourceforge.net
Subject:
Not marked for installation means that the custom action can't run because
the target file isn't going to be installed. That could be a consequence of
your feature/component arrangement, although sometimes you get it if there is
an existing file of an equal or higher version so the one in your
Well it's the usual and required behavior for a per-user install to add
the entries to the current user's hive. It's not particularly secure if
a per-user install adds system-wide COM registration so that anyone on
the system can use it. It's regsvr32 that's rather limited here because
it doesn't
There isn't a data item called ProductVersion under those those registry
keys.
Why not use a component guid in an AppSearch instead?
Phil Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Harvey
Werner
Sent: Monday, February 12, 2007 2:09 PM
It's not Wix as much as it is that Windows Installer property names are
case-sensitive (one of the reasons being that all uppercase means that
it's a public property).
Phil Wilson
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andy Ness
Sent:
.
I presume there may be a way of saying Only do on install and if server
feature selected. Do you know what this syntax is?
Wilson, Phil wrote:
Not marked for installation means that the custom action can't run
because the target file isn't going to be installed. That could
Try microsoft.public.platformsdk.msi.
Phil Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Harvey
Werner
Sent: Thursday, February 15, 2007 9:20 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Forum for Windows Installer questions?
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:
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
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
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 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:
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.
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
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
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
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
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
, 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
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:
Well not really. An admin install isn't anything to do with the actual running
installed product, it just extracts the files out, which is probably what you
want to prevent (why?). If you think you've concealed your files by preventing
an admin install, good luck with that! Also, beware that an
How can this save testing? You're going to invent something like a custom
action to check various combinations of properties (and I don't know what that
would be) and you're not going to test it? You'd need to test that right-click
an MSI file and Repair does what you expect, that any repair
Assuming I understand what you're asking, I think the official support for this
is available only in MSI 4.5:
http://msdn.microsoft.com/en-us/library/bb736308(VS.85).aspx
Where does your PATCHFOUND property come from?
Phil Wilson
-Original Message-
From: Sandeep Kumar Bushnam
and something else to check is that InstallShield sometimes uses a thing
called version lying. It's called lying because the File table in the MSI
file gets a version of 65535.65535 etc so it always replaces any existing
file on the system. If you managed to transfer something like
Basically you make them elevated by marking them deferred and sequencing them
between InstallInitialize and InstallFinalize.
Phil Wilson
-Original Message-
From: Andy2k8 [mailto:appr...@gmail.com]
Sent: Wednesday, January 13, 2010 10:25 AM
To: wix-users@lists.sourceforge.net
Subject:
Are you sure about that WinSxS location? I believe the 7.1 merge modules will
install the Dlls in the user's application folder. I don't think they went
WinSxS until Visual Studio 2005.
Phil Wilson
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent:
1 - 100 of 977 matches
Mail list logo
