Hello Rob,
My guess is that running the MSI from an elevated bootstrapper (not
burn) causes the issue. I now use to force the
folders to be writeable for "Users". Probably a better approach than
relying on the installing user.
Theo
Op 23-4-2013 1:24, Rob Mensching schreef:
> Did you ever get th
Hi All
Below shown is my directory structre.
I am changing DIRVMSOS Dynamically with type 35 custom action.
This custom action only changes DIRVMSOS value not the child directory
value.
f
Did you ever get this sorted out?
On Tue, Apr 9, 2013 at 5:57 AM, Theo Landman wrote:
> Hello,
> I'm confused about how Impersonate works. I want to run a console
> migration executable using the WiX CAQuitExec. The migration executable
> copies files from a previous version of the product to a
If the "[LogPathVariable]" was passed as an empty string that means the
variable was interpreted, it just interpreted to empty string. Logging for
ExePackage's has to be done essentially manual since .exe based installs
are all very different. However Burn provides a little to help you. The
followi
you have to magae the case when the Command.Display is not Full.you can see the
InstallationViewModel provided in the Setup of wix, expecially in the functions
DetectComplete and ApplyComplete
> From: nmil...@livetechnology.com
> To: wix-users@lists.sourceforge.net
> Date: Mon, 22 Apr 2013 21:09
Hi All,
I am trying to upgrade an msi from a custom managed bootstrapper. For some
reason the upgrade fails when trying to remove the cached bootstrapper package.
When the installer tries to run C:\ProgramData\Package
Cache\...\MyCustomBa.exe -uninstall -quiet -burn.related.upgrade it just
l
That particular issue has been discussed before and we'd like to have a
solution for it that doesn't require pre-elevating. Know how, just haven't
had the solution written.
On Mon, Apr 22, 2013 at 10:58 AM, Carlos Alberto Costa Beppler <
bepp...@gmail.com> wrote:
> Hi, but it would be nice to ha
Thanks John.
Sorry for maybe easy questions here, but we are still new to WiX and therefore
I could use a bit more information.
1. So you are placing all the dependencies into your Binary Table?
2. When you say you deploy them with a custom action, how do you extra them
from the custom action t
Thanks Jacob, but does this Payload element only work with bootstrapper .exe
installs?
We are only making .msi install packages and therefore would this Payload
element work in this case?
Thanks,
Tim.
From: Hoover, Jacob [via Windows Installer XML (WiX) toolset]
[mailto:ml-node+s687559n75853
The preferred method I like to use is to:
1) carry around my binary dependencies for a custom action in the Binary Table;
2) deploy them and set them up with a preparatory custom action in a sub-bolder
of the TEMP tree;
3) run the custom action itself from inside that sub-folder;
4) clean up the
Burn would support this, via Payload elements. In 3.8, the current directory is
set to the folder for the payload when the Package is being executed.
-Original Message-
From: TimM [mailto:timmay...@smarttech.com]
Sent: Monday, April 22, 2013 1:58 PM
To: wix-users@lists.sourceforge.net
Su
Ah, that makes sense. Thanks for following up, I will be able to incorporate
the uninstall into a couple of scripts that I use :-)
Gary
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Installing-wix-without-user-interaction-tp7585341p7585347.html
/q did the trick, thanks for the quick response!
With some more poking around I discovered /q /uninstall will run the
uninstall silently.
On Mon, Apr 22, 2013 at 11:35 AM, Gary Park wrote:
> Hello,
>
>
> For installation, the /q flag should allow you to do a silent install.
>
>
> Not sure abou
Hello,
We are converting over one of our InstallShield install project to WiX and
would like to know if WiX has a install support folder?
Our InstallShield project has a custom action that calls an app that
requires 5 files to be in the same folder so that the custom action works.
These files are
Hello,
For installation, the /q flag should allow you to do a silent install.
Not sure about uninstall though.
Hope that helps!
Gary
Sent from Windows Mail
From: Keston Obendorf
Sent: Monday, 22 April 2013 19:23
To: wix-users@lists.sourceforge.net
Are there any command lin
WiX doesn't show a UI by default; you need to explicitly add UI elements, no?
Source: Getting Started Tutorial -->
http://wix.tramontana.co.hu/tutorial/getting-started
Alain
-Original Message-
From: Keston Obendorf [mailto:pikthu...@gmail.com]
Sent: April 22, 2013 14:19
To: wix-user
Are there any command line arguments one can run the wix37.exe installer
with to cause it to install/uninstall without user interaction?
--
Precog is a next-generation analytics platform capable of advanced
analytics on sem
Hi, but it would be nice to have an option to change the manifest.
I want this because we have to install web applications on IIS and want to
show options to user to select in which website and which application pool
the web application should run.
On IIS 7+, only admin users can access this kind
I have tried with this but the [LogPathVariable] is not valuated and Burn pass
an empty string as args, so the exe package report an error, and doesn't
install.
> From: jacob.hoo...@greenheck.com
> To: wix-users@lists.sourceforge.net
> Date: Sun, 21 Apr 2013 21:21:42 +
> Subject: Re: [WiX-us
Sure. I'll contribute it.
--
John M. Cooper
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Monday, April 22, 2013 11:29 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Plans to update the POWERSHELLVERSION Property in PS
Seems reasonable probably not implemented originally because we didn't
expect many layout-only Payloads. They are usually very rare (like maybe an
autorun.inf or readme.txt).
On Thu, Apr 18, 2013 at 10:56 AM, tom wrote:
>
>
> add
>
> PackageGroupRef inside the chain
>
>
>
>
> --
> View this mes
If someone contributes it, yes. Want to send a pull request against wix38
with that?
On Mon, Apr 22, 2013 at 9:05 AM, John Cooper wrote:
> I've got a product that now has a dependency on PowerShell version 3.0.
> The POWERSHELLVERSION property in the PS extension only probes the v1/v2
> locatio
I've got a product that now has a dependency on PowerShell version 3.0. The
POWERSHELLVERSION property in the PS extension only probes the v1/v2 location.
Are there plans to either add a POWERSHELLVERSION3 property or otherwise extend
detection of installed PowerShell to include PowerShell v3?
Not aware of a workaround for a system feature. Task scheduler is an
interesting idea for Vista+. Might add a chunk of complexity. Something
someone could investigate if really interested.
On Mon, Apr 22, 2013 at 1:00 AM, rowbot wrote:
> Found this..
>
> http://support.microsoft.com/kb/2021405
This only works if UAC is disabled...
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Failure-0x8007051b-tp7578778p7585331.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Found this..
http://support.microsoft.com/kb/2021405
So it's a feature.. can this be worked around using Burn?
Should it use Task Scheduler to deal with reboots?
Thanks,
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-not-restarting-if-do
26 matches
Mail list logo
