Tim,
Wixtoolset.org has a link to the bug tracker.
As for localizing, you would need to create a WXL file for the bundle. When
you include it in the payload via a Payload element, I believe they all need
the same file name but should be located in LCID specific sub folders. As for
the nam
Rob, where do I go to create a bug for this?
As a side not we are using just the standard Burn UI - License dialog box and
option directory dialog box and we need to have these translated if running in
a different language. So what do I have to add or modify so that I can get the
standard UI to
Hmm, well, certainly seems to be something going wrong but can't tell what
exactly based on the log files. Would be a great idea to open a bug with as
many details about the issue as possible.
On Wed, Jul 24, 2013 at 5:06 AM, TimM wrote:
> Sorry about that
>
> Try this link: https://www.dro
MSP didn't fail because Burn recognized it wasn't to be installed:
Planned package: cs201022_HotFix00,
state: Absent, default requested: Present, ba requested: Present, execute:
None, rollback: None, cache: No, uncache: No, dependency: None
On Wed, Jul 24, 2013 at 3:24 AM, rowbot wrote:
> Hi
Sorry, missed the forks of this thread. Essentially what you are asking for
is that something on the system says, "This new version of the software is
safe because the old software is on the machine." As Jacob mentioned there
are *a lot* of security issues to consider when implementing such a syst
Can you provide more details about how you are executing elevation?
On Wed, Jul 24, 2013 at 8:25 AM, Hoover, Jacob
wrote:
> Wix/Burn doesn't have a service portion written so it's dependent on
> Windows Installer constraints. If there is a need to update without admin
> privileges, either an Adm
What conflicts are you worried about exactly? One or more specific user
scenarios that expose the issue you think there is in Burn would probably
help a lot.
On Wed, Jul 24, 2013 at 3:58 AM, Tomas Köhn wrote:
> I agree, burn has a lot of cool features.
>
> Our problem is that administrators expe
Thank you again, I will look into C# Custom Actions.
José
On Wed, Jul 24, 2013 at 3:02 PM, Steven Ogilvie wrote:
> Classification: Public
> I have written a custom action C# DLL
>
> The custom action is called within the product.wxs:
>
> Value="$(var.ProductName)"/>
> DllEntry="CheckToSeeI
I had wix doing the .Net 4.0 for me. I had seen Neil's blog some time ago
but did not find it when I needed the .Net 3.5 info. Thanks for the info!
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Re-RemotePayload-causes-error-LGHT0103-The-system-
Correct
Thanks for the help, I was trying to simplify things by ignoring per user but
it looks like I need to dig into it.
-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Wednesday, July 24, 2013 10:58 AM
To: General discussion for Windows Installer XML
Burn is prompting for credentials.
-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Wednesday, July 24, 2013 10:51 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] prompt for administrator account during major upgrade
[P
Again,
If the install is Per-Machine then Burn is going to request elevation. The
only way to avoid this is to make it a per-user install or have an
administrator deploy the updates.
One could write a service which is going to be ran as admin (to service the
update), however this opens up a
Classification: Public
How are you asking the user to give the administrator account then?
-Original Message-
From: Mike Myers [mailto:mike.my...@naucountry.com]
Sent: July-24-13 11:43 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] prompt for administ
I do not have any custom actions in my install beyond what is included in wix.
-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Wednesday, July 24, 2013 10:29 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] prompt for ad
Classification: Public
You can let the bundle.wxs handle the .NET 4.0 installation for you.
You will need to reference the .NET WIX extension then just add:
To install .net 3.5 check out Neil Sleightholm's blog and goto the .NET
Framework 3.5 SP1 Install :)
http://neilsleightholm.blogs
Classification: Public
Is this a custom action you are using?
Anyway you could use something like:
NOT
WIX_UPGRADE_DETECTED
-Original Message-
From: Mike Myers [mailto:mike.my...@naucountry.com]
Sent: July-24-13 11:02 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] prompt fo
Wix/Burn doesn't have a service portion written so it's dependent on Windows
Installer constraints. If there is a need to update without admin privileges,
either an Administrator must push the updates via a tool like SCCM/AD/etc, or
the install/app would need to be reworked as a per-user applica
I have a wix install with burn bootstrapper. My situation deals with a
non-administrator installing this on a machine. The user is prompted for an
administrator account. When a major upgrade happens, the user is prompted for
an administrator account again. Is there any way to prevent a user
I have a bundle based on WixStdBa which installs .Net 4.0 and my MSI. I need
to add a third party MSI which requires .Net 3.51. So at this point I am
only trying to add .Net 3.51 to my chain. Not finding a built-in way to do
this like I did for .Net 4.0 ( '') I am
using info from:
http://stacko
Classification: Public
I have written a custom action C# DLL
The custom action is called within the product.wxs:
CA: Checking for Microsoft Message
Queuing Service (MSMQ)...
NOT Installed
NOT
Installed
-Original Message-
From: José Marques [mailto:jose.marq...@w
Thank you for your reply.
I am a bit new to Wix, as this is the first time I'm making an installer,
where exactly do you write that code? I presume it's not straight into the
xml, but so far I only have written XML...
Best regards,
José
On Wed, Jul 24, 2013 at 2:09 PM, Steven Ogilvie wrote:
> Cl
Classification: Public
I have the same requirements and ended up writing a custom action to do the
work for me:
>From Windows 7/8/2008R2/2012 I use Dism.exe for OS's below I use ocsetup.exe
>(we use MSMQ for our Server product and our Client product), however Microsoft
>being so consistent (bein
Sorry about that
Try this link: https://www.dropbox.com/s/5ersyy950w54fdy/ErrorLogfile.zip
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-3-7-Burn-error-0x80004005-Failed-to-extract-all-files-from-container-tp7587152p7587541.html
Sent fro
I agree, burn has a lot of cool features.
Our problem is that administrators expects an .msi for easy remote deployment,
while other, smaller customers want to have an setup.exe with checks dependency
(.NET framework, OS etc.).
If we at first installs with setup.exe, we might later have to inst
Hello all,
On the installer I'm currently developing, I need to install Microsoft
Message Queue (MSMQ) as a dependency. Depending on Windows version, I need
to run ocsetup.exe or sysocmgr.exe. No issues with ocsetup, my problem
relies with sysocmgr.
So far I've thought of two ways to do it: add an
Hi,
Can anyone tell my why a patch bundle installs successfully even though the
patch inside didn't?
If I run the MSP on an invalid RTM product, I get the usual message.
>From the log:
[07AC:0B2C][2013-07-24T11:14:47]i201: Planned package: cs201022_HotFix00,
state: Absent, default requested: Pr
26 matches
Mail list logo
