I want to create a shortcut to point to my executable. The shortcut will be
used in cases where the .exe needs to run with elevate privileges. I don't
see any attribute(s) in the schema that can allow me to create the shortcut
with this flag.
So, is it up to me to deliver the .LNK file myself?
elevation/run
as
admin privileges ?
-Original Message-
From: Andy Clugston [mailto:clug...@gmail.com]
Sent: 25 September 2012 18:23
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Shortcut Element Run as administrator
I want to create a shortcut to point
executes the source app (same folder).
-Original Message-
From: Andy Clugston [mailto:clug...@gmail.com]
Sent: Tuesday, September 25, 2012 12:46 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Shortcut Element Run as administrator
Due to an issue with the IISExtension and how it handles certs in WiX 3.0
we are unable to uninstall/upgrade our product (see other recent issues I
have been asking about). I have attempted to create a substitute MSI DB to
replace the cached DB file per Rob's recommendations here:
G20 0SP
Email Disclaimer
-Original Message-
From: Andy Clugston [mailto:clug...@gmail.com]
Sent: 30 August 2012 12:57
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Replacing Cached MSI DB
Due to an issue with the IISExtension and how it handles
in any of the tables. Where do I
find this so that I can make the package GUID in my replacement MSI the
same? This is all assuming the package GUID has anything to do with the
issue I am seeing.
Thanks.
On Thu, Aug 30, 2012 at 10:09 AM, Andy Clugston clug...@gmail.com wrote:
Well, like I said I
may be to try to build your MSI using WiX
v3.0 but with the WiX v3.5 IIS extension. That's not technically supported
either but it *may* work out.
On Thu, Aug 30, 2012 at 7:09 AM, Andy Clugston clug...@gmail.com wrote:
Well, like I said I am using * for the components that allow
Dario, did you ever find a resolution to this issue?
On Wed, Sep 22, 2010 at 8:52 PM, Bob Arnson b...@joyofsetup.com wrote:
On 22-Sep-10 20:15, Dario Amiri wrote:
So it looks like no one has any advice for this issue. Is there any way
I can submit this as a bug?
The WiX home page has
.
On Tue, Aug 28, 2012 at 10:24 PM, Andy Clugston clug...@gmail.com wrote:
So I created a new version (major upgrade) of the product. I adjusted
RemoveExistingProducts to run after InstallFinalize. This didn't seem to
help at all. It still attempts to remove the cert, and I have the same
errors
We have a product that installs a few certificates on the system using the
IIS extension using WiX 3.0. Evidently, there is an issue with the
certificate action(s) in this version of the toolset.
We are unable to uninstall/upgrade from this specific version in the field.
I would like to know if
reference would retain the component on the machine until you took
both
installers off.
-Original Message-
From: Andy Clugston [mailto:clug...@gmail.com]
Sent: 28 August 2012 16:15
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Conditional Uninstall - Need
the same thing with the second product too since you don't
know which one will be removed last and will perform the actual certificate
uninstallation.
-Original Message-
From: Andy Clugston [mailto:clug...@gmail.com]
Sent: 28 August 2012 17:20
To: General discussion for Windows
So I created a new version (major upgrade) of the product. I adjusted
RemoveExistingProducts to run after InstallFinalize. This didn't seem to
help at all. It still attempts to remove the cert, and I have the same
errors.
Thanks.
On Tue, Aug 28, 2012 at 3:26 PM, Andy Clugston clug...@gmail.com
As I understand from MSDN ...The *MsiFileHash* table can only be used with
unversioned files... Within WiX is it possible to force the use of this
table for file components of versioned file types?
Thank you.
--
.
Chris
From: Andy Clugston clug...@gmail.com
Sent: Thursday, March 08, 2012 8:07 AM
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Subject: [WiX-users] MsiFileHash table
As I understand from MSDN
I am working with the Windows Installer APIs (msi.dll). I would like to be
able to harvest the paths of file components of certain products installed
on the system. I am currently using the automation interface and what I am
finding when calling get_ComponentPath() is that the full path is only
-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.
Subject: [WiX-users] Windows Installer and Process Environment Block
I am working on an installation sequencer. The heart
I am working on an installation sequencer. The heart of the sequencer is a
Windows system service that launches the install processes (typically
msiexec) as they come in.
The sequencer service is grabbing the environment block of the logged on
user (this has been verified) and passing this block
, but if anyone
has any ideas...
Thanks.
On Mon, Feb 13, 2012 at 7:05 AM, Andy Clugston clug...@gmail.com wrote:
Hello,
I am attempting to use the WixQueryOsWellKnownSID action to query the
localized group names for the Administrators and Users groups. In general,
per the log file the action appears
All,
Is there a way to apply system policies similar to how one would use
secedit.exe? I currently have a custom action that runs secedit.exe which
works fine, but the trouble is that my current approach does not work well
with localized versions of Windows (i.e. the command line arguments
Hello,
I am attempting to use the WixQueryOsWellKnownSID action to query the
localized group names for the Administrators and Users groups. In general,
per the log file the action appears to be running and exiting but is still
returning the English spelling of these groups thus causing the
I have a WiX 3.0 installer that works okay on XP SP3, but when attempting
to install on Windows 7 Pro SP1 I see the following error:
Action ended 18:33:17: InstallFinalize. Return value 3.
Both systems are 32 bit operating systems, Win7 system has UAC disabled.
It appears to be getting through
, Nov 18, 2011 at 2:46 PM, Andy Clugston clug...@gmail.com wrote:
I have a WiX 3.0 installer that works okay on XP SP3, but when attempting
to install on Windows 7 Pro SP1 I see the following error:
Action ended 18:33:17: InstallFinalize. Return value 3.
Both systems are 32 bit operating
that of the domain the machine is in -
for instance if you are logged in as a local account on the machine
USERDOMAIN will be the computer name. I have not found an environment
variable that gives you this.
Michael
From: Andy Clugston [clug...@gmail.com]
Sent
the user's domain either.
You could try getting what you want from environment variables.
http://blogs.msdn.com/b/windows_installer_team/archive/2005/09/16/461742.aspx
Just make sure the variable you check is available on all the OSes you
support.
-Original Message-
From: Andy Clugston
Hi All,
I am looking for a quick way to determine if a system is on a specific
domain when running an install. Can the LogonUser or Computer name property
be used to derive this information? Is there another property that might
help? I'm trying to avoid a custom action, but I'm not sure I can.
Ditto. Very interested in this topic as well.
Thanks.
On Thu, Apr 21, 2011 at 8:49 PM, lambda...@hushmail.com wrote:
Hi,
Is it possible for WiX binaries and the MSI (eg Wix35.msi) to be
digitally signed by the WiX team? Alternatively is it possible for
an authoritative team member to post
Seems to be a popular topic lately...
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Windows-7-MSI-privileges-td617.html
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Windows-7-MSI-privileges-td617.htmlAs
Pally said, setting the property is the proper
What you are running into is UAC, Google it if you have not already.
You need Execute=deferred custom actions with Impersonate=no. This will
allow your custom actions, and subsequent child processes that they create,
to inherit the local system privileges of the Windows Installer service.
There
All,
I currently have the prevent downgrade custom action below...
Custom Action='NoDowngradeAction'
After='FindRelatedProducts'NEWERFOUND/Custom
CustomAction Id='NoDowngradeAction' Error='Installation aborted. A later
version of [ProductName] is already installed.' /
One thing that I am tasked
I believe I found a way to accomplish this. Using the OnExit=error as well
as some other properties I already had setup seems to be working.
On Tue, Feb 22, 2011 at 3:38 PM, Andy Clugston clug...@gmail.com wrote:
All,
I currently have the prevent downgrade custom action below...
Custom
When you create your new version what specifically is changing? Other than
the deliverables/updates of course...
- Anything changing with ProductGuid, UpgradeCode, etc?
- Are you only bumping the 4th digit, 1.1.0.2, 1.1.0.3, 1.1.0.4, etc.?
- Is your MSI file name changing?
I've had success doing
Hi Users,
I am working the kinks out of an MSI to support 64 bit. This is an x86 MSI
that will run in WOW64 on x64 systems.
The issue I am seeing is that the PROCESSOR_ARCHITECTURE is set to x86
(rather than what the base OS architecture is; i.e. AMD64) within a custom
action that is running.
.
Are there some help resource avaiable?
Thanks
On Fri, Jan 21, 2011 at 11:17 AM, Wilson, Phil phil.wil...@invensys.com
wrote:
Use MSI 4.5 - it got restored there.
http://support.microsoft.com/kb/942288
Phil Wilson
-Original Message-
From: Andy Clugston [mailto:clug
Yep. Thanks for the reply.
On Sat, Jan 22, 2011 at 11:31 AM, Rob Mensching r...@robmensching.comwrote:
Yeah, 32-bit processes on 64-bit Windows get PROCESSOR_ARCHITECTURE=x86.
Start up a 32-bit cmd.exe and you'll see the same thing.
On Sat, Jan 22, 2011 at 3:58 AM, Andy Clugston clug
...@invensys.com
wrote:
Use MSI 4.5 - it got restored there.
http://support.microsoft.com/kb/942288
Phil Wilson
-Original Message-
From: Andy Clugston [mailto:clug...@gmail.com]
Sent: Thursday, January 20, 2011 6:35 PM
To: General discussion for Windows
://msdn.microsoft.com/library/aa384274.aspx
-Blair
-Original Message-
From: Andy Clugston [mailto:clug...@gmail.com]
Sent: Saturday, January 22, 2011 9:26 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] PROCESSOR_ARCHITECTURE - x86 MSI on 64bit
explorer and look at a system service, you will typically
see the SeBackupPrivilege being present, but in the disabled state. From
my understanding, when the API needs this privilege it enables it, uses it,
then disables it again.
On Sat, Jan 22, 2011 at 8:42 PM, Andy Clugston clug...@gmail.com
Hi Users,
I am working on a product that needs to support Windows 7 w/ UAC enabled.
The MSI has a few custom actions that perform various configuration items
that I would like to keep contained within the MSI/product install.
The custom actions are Execute='deferred' with Impersonate='no' and
workarounds are welcome. :)
On Thu, Jan 20, 2011 at 3:33 PM, Andy Clugston clug...@gmail.com wrote:
Hi Users,
I am working on a product that needs to support Windows 7 w/ UAC enabled.
The MSI has a few custom actions that perform various configuration items
that I would like to keep contained
Hi Users,
I am running into a bit of an issue while attempting to hook a C++ dll
custom action into my installer. From all my research and debugging it
appears that I have things setup properly. I have some tracing (message
boxes) to indicate when DLLMain is entered/exited as well as my CA
Yes, that was it!
I guess I have been out of native development too long... Thanks for the
reminder on the function export.
Thanks again!
On Wed, Jan 5, 2011 at 10:50 AM, Leonidas Spyropoulos
leonidas.spyropou...@formicary.net wrote:
On 05/01/2011 15:30, Andy Clugston wrote:
Hi Users,
Hey
Hi WiX Users,
Is it possible to target a user's hive (other than the logged on user)
during the install process? I did a quick review of the Registry elements
and didn't see anything jump out at me.
Thanks!
--
Lotusphere
Hi All,
After doing some searching, it seems that the general understanding is that
Windows Installer does a poor job with exit codes returned when an MSI does
not complete successfully for some reason. A case that we have encountered
is where we are preventing downgrades for our install
Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Tuesday, November 30, 2010 7:03 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Understanding Windows Installer Exit (Error) Codes
Sadly, no.
On Tue, Nov 30, 2010 at 5:33 AM, Andy
of 1.0.1 using the same
infrastructure, everything works just fine.
Thanks again.
On Thu, Jul 1, 2010 at 9:42 AM, Andy Clugston clug...@gmail.com wrote:
Alright, thanks.
On Tue, Jun 29, 2010 at 11:14 PM, Rob Mensching r...@robmensching.comwrote:
No problems if you use a major upgrade and schedule
Hi Mike,
Thanks for the info. What you stated is what I am seeing in the verbose
logs. I see where the files are being copied, and then I see where they are
being removed. Doing a diff between the good v1.0.0 case and the bad
v1.0.0 case makes it obvious.
So if I understand you on the
stuck with
specifying
a GUID.
--
virtually, Rob Mensching - http://RobMensching.com LLC
On Tue, Jun 29, 2010 at 5:29 PM, Andy Clugston clug...@gmail.com wrote:
v1.0.0 of a particular product was shipped with hard coded GUIDs. So, if
I
change to * for version 1.0.1, I will have issues
I am trying to determine the best approach to take with creating GUIDs for
the various WiX elements. We use a full upgrade approach so I believe for
the Product Id=* is okay. It probably goes without saying that setting
Package Id=* makes sense in all cases. It is my understanding that the
-Original Message-
From: Andy Clugston [mailto:clug...@gmail.com]
Sent: Tuesday, June 29, 2010 7:35 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Best Practices - Using * for GUID automation
I am trying to determine the best approach to take with creating
in with a time when you wouldn't want to use * on
component Guids? Would this cause issues with generating patches?
-James
On Tue, Jun 29, 2010 at 1:19 PM, Andy Clugston clug...@gmail.com wrote:
Okay, it seemed like this approach would work, just wanted to verify.
Thanks!
On Tue, Jun 29
I am trying to work through some automation scenarios regarding heat and
some file-dependent Components. Here is the scenario... I have a product
that consists of a set of .exes and dlls. I would like to use heat.exe to
automatically generate these deliverables for me at build time. It does
I have found a few indications online that heat.exe does not support
converting a .reg file to the WiX .wxs format. The suggestions I ran across
show to use tallow.exe from WiX v2. Is it true that v3+ does not support
this any longer? Also, the download for v2 is broken.
Thanks.
can use the fact that Windows Installer ignores fourth
version field to detect when none of the first three have changed. See
my post from last week for more info.
Sascha
On Tue, Apr 20, 2010 at 6:38 AM, Andy Clugston clug...@gmail.com wrote:
I am attempting to determine if a specific
I am attempting to determine if a specific version of a product is already
installed on the system. I basically want to do this to disallow/bail out
of an install if the MSI that is being executed is already installed on the
system.
Here is my authoring using 3.0 RTM. I must be missing something
I am not 100% sure, but I doubt WiX has this built in. I use signtool.exe
to sign the MSI after WiX is done with it. Works good, and is probably a
little more flexible in the long run anyway.
On Tue, Apr 13, 2010 at 12:03 PM, jeff00seattle
jeff_tan...@earthlink.netwrote:
Hi
Curious, does
Okay, great. I will get info up there today. Thanks.
On Sat, Apr 10, 2010 at 8:58 AM, Bob Arnson b...@joyofsetup.com wrote:
On 4/9/2010 8:06 AM, Andy Clugston wrote:
You sure? Still looks closed.
I hate bad Web apps. Open now.
--
sig://boB
http://joyofsetup.com
You sure? Still looks closed.
Thanks.
On Thu, Apr 8, 2010 at 5:13 PM, Bob Arnson b...@joyofsetup.com wrote:
On 4/8/2010 9:55 AM, Andy Clugston wrote:
Upgrading to the RTM (5419) did not help. Same issues.
I reopened the old bug. Please attach sample authoring and a verbose log
showing
Upgrading to the RTM (5419) did not help. Same issues.
Thank you.
On Thu, Apr 8, 2010 at 8:44 AM, Bob Arnson b...@joyofsetup.com wrote:
On 4/7/2010 7:49 AM, Andy Clugston wrote:
WixIIsExtension.dll version: 3.0.5217.0
Try upgrading to WiX v3.0 RTM.
--
sig://boB
http
One of our products is required to install three certificates. There is a
possibility that one of our certificates may have already been pushed down
to the end user system via IT. I have ran across an issue which appears to
mimic the issue reported in the 2184946 tracker report.
In our case,
60 matches
Mail list logo
