-- Yan
-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com]
Sent: Tuesday, January 20, 2009 7:36 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in iis:WebApplication?
Thanks, I'll bring this to Mike's attenti
Thanks, I'll bring this to Mike's attention when we meet on Thursday.
-Original Message-
From: Yan Sklyarenko [mailto:y...@sitecore.net]
Sent: Tuesday, January 20, 2009 08:15
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in iis:WebA
Done: #2524017
-- Yan
-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com]
Sent: Tuesday, January 20, 2009 5:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in iis:WebApplication?
Yeah, sounds like a bug. Mike made
]
Sent: Tuesday, January 20, 2009 02:51
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Bug in iis:WebApplication?
Hello WiX community,
It seems I have found a bug in IIS extension. I hope I'm wrong and
somebody will point me to my mistake.
First of all, WiX ve
Hello WiX community,
It seems I have found a bug in IIS extension. I hope I'm wrong and
somebody will point me to my mistake.
First of all, WiX version is 3.0.4917.0. I'm trying to configure the
existent website in IIS 5.1. Here is my component definition:
IISMAJORVERSION = "#5"
Ah, so it is. Thanks for the correction!
-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com]
Sent: Tuesday, January 13, 2009 6:06 PM
To: Rob Mensching; General discussion forWindows Installer XML toolset.
Subject: Re: [WiX-users] Bug with Component/@Guid
Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug with Component/@Guid="*"?
As an addendum to this issue: I'm installing a web service, and it needs to
be installable on both 64 bit and 32 bit systems.
Is it possible to build a wix that will install into both, or do I need to
for Windows Installer XML toolset.
> Subject: [WiX-users] Bug with Component/@Guid="*"?
>
> I have a bunch of component/files rooted under ProgramFilesFolder64.
> Using "*" for the Component's Guid gets me:
>
> error LGHT0231: The component &#x
ew [mailto:j...@liquidmachines.com]
Sent: Tuesday, January 13, 2009 13:50
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Bug with Component/@Guid="*"?
I have a bunch of component/files rooted under ProgramFilesFolder64.
Using "*&
Yes, bug. 64 bit folders aren't evaluated. Please open it against "light"
"v3.0".
-Original Message-
From: Jeremy Lew [mailto:j...@liquidmachines.com]
Sent: Tuesday, January 13, 2009 13:50
To: General discussion for Windows Installer XML toolset.
Subj
I have a bunch of component/files rooted under ProgramFilesFolder64.
Using "*" for the Component's Guid gets me:
error LGHT0231: The component 'C__d8f4a26fe53142ebb42d1a9fdf527ac6' has
a key file with path 'TARGETDIR\lmdc
server\adminui\branchadmindisabled.aspx'. Since this path is not rooted
in
Peter Oehlert wrote:
> It seems that when creating the wix project a file called product.wxs is
> included in the package and then the name is changed to the name of the
> project.
Which version of WiX are you using? In v3.0.4827, there's no such rename.
--
sig://boB
http://joyofsetup.com/
-
It seems that when creating the wix project a file called product.wxs is
included in the package and then the name is changed to the name of the
project. So calling the project database ultimately has a database.wxs file
that is added to source control.
Well, for whatever reason I'm seeing that th
AIL PROTECTED]
Sent: 22 October 2008 19:26
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in x64 build of WiX UtilExtension?
XmlConfig does not automatically create an uninstall step for you. That's why
there is the "On" attribute. You ge
Sent: Wednesday, October 22, 2008 10:52
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in x64 build of WiX UtilExtension?
I think the problem here is that there is no corresponding "uninstall" action
for an operation like the following:
(Sample
||/@[EMAIL PROTECTED]@:^[-['^";@@@\\>])@.".
"{)/];)^{";$,+=(++$,);$_.=">&$,";`$_`;
-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 22, 2008 10:09 AM
To: General discussion for Windows Installer XML toolse
toolset.
Subject: Re: [WiX-users] Bug in x64 build of WiX UtilExtension?
Hmm, I guess there is no straightforward way to edit existing values in an XML
file with XmlConfig. As you mention, if it were possible, it would make it
hard to rollback changes if something goes wrong (it would somehow have
";$,+=(++$,);$_.=">&$,";`$_`;
-Original Message-
From: Joel Paula (hotmail) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 22, 2008 9:27 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Bug in x64 build of WiX UtilExtensi
ay, October 22, 2008 4:47 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in x64 build of WiX UtilExtension?
I'd recommend using XmlConfig instead of XmlFile. The following should achieve
what you want:
This blog post has some more examples of using XmlCon
XmlFile is limited. That's why we created XmlConfig.
-Original Message-
From: Joel Paula (hotmail) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 22, 2008 09:11
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Bug in x64 build of Wi
ation.
Example using XmlConfig:
HTH
Joel
-Original Message-
From: Pally Sandher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 22, 2008 2:12 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Bug in x64 build of WiX UtilExtension?
I'm trying to use util:XMLFile to m
Message-
From: Pally Sandher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 22, 2008 2:12 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Bug in x64 build of WiX UtilExtension?
I'm trying to use util:XMLFile to modify the inner text of a tag in an XML file
during install
.aspx
##
$_='^#(/||/@[EMAIL PROTECTED]@:^[-['^";@@@\\>])@.".
"{)/];)^{";$,+=(++$,);$_.=">&$,";`$_`;
-Original Message-
From: Pally Sandher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 22, 2008 6:12 AM
To: wix-users@lists.sourc
I'm trying to use util:XMLFile to modify the inner text of a tag in an XML file
during installation which is installed by my MSI for one of our plug-ins.
The XML file is named IESveInterfaceParameters.xml and contains the following
code:
M:\IES\apps
My installer code is as follow
Re:
<http://sourceforge.net/mailarchive/message.php?msg_name=139942F2536B7C4FBDE
6B44132F80C842426B1D318%40NA-EXMSG-C111.redmond.corp.microsoft.com>
[WiX-users] Bug in wix.ca.targets version 3.0.4318.0?
From: Jason Ginchereau <[EMAIL PROTECTED]> -
>>
>> Brian Gillespie
>> Rhinoceros Development
>> Robert McNeel & Associates
>>
>> Rob Mensching wrote:
>>
>>> References start at the Product and work down. If a Fragment does not
>>>
>> get a reference int
ECTED]
Sent: Wednesday, October 08, 2008 9:02 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Bug in wix.ca.targets version 3.0.4318.0?
Hi Jason,
I have checked the GAC and yes the dll IS in there. The "dependant
assembly..." IS also output. I just verified this again
urceforge.net/mailarchive/message.php?msg_name=139942F2536B7C4FBDE
6B44132F80C842426B1D208%40NA-EXMSG-C111.redmond.corp.microsoft.com>
[WiX-users] Bug in wix.ca.targets version 3.0.4318.0?
From: Jason Ginchereau <[EMAIL PROTECTED]> - 2008-10-08 15:10
That DLL is deliberately no
amework or
other redistributable), and therefore are not included in the CA package.
-Jason-
-Original Message-
From: Nic Barden [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 08, 2008 6:14 AM
To: WiX User Group
Subject: [WiX-users] Bug in wix.ca.targets version 3.0.4318.0?
Hi,
I cr
Hi,
I created a CA using version 3.0.4318.0 of WiX. When I ran the CA that was
built via an installer, I received the error "Failed to load assembly
Microsoft.Deployment.WindowsInstaller. Error code 0x80070002". Upon checking
the C:\Program Files\MSBuild\Microsoft\WiX\v3.0\wix.ca.targets fil
necessary.
-Original Message-
From: Brian Gillespie [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 07, 2008 16:53
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in FeatureRef?
Hi Rob,
> References start at the Product and work down. If a
t a reference into it, it will never be included in the build. Would that
> explain the behavior you are seeing?
> >
> > -Original Message-
> > From: Brian Gillespie [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, October 07, 2008 15:13
> > To: wix-users@lis
15:13
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Bug in FeatureRef?
>
> WiX release 3.0.4513.0
>
> When I use a ComponentRef inside a FeatureRef inside a Fragment file,
> the File in my single Component doesn't end up in my MSI. However, if I
> move the
:13
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Bug in FeatureRef?
WiX release 3.0.4513.0
When I use a ComponentRef inside a FeatureRef inside a Fragment file,
the File in my single Component doesn't end up in my MSI. However, if I
move the FeatureRef into the main Product fil
WiX release 3.0.4513.0
When I use a ComponentRef inside a FeatureRef inside a Fragment file,
the File in my single Component doesn't end up in my MSI. However, if I
move the FeatureRef into the main Product file, it works as I expect.
Confused? Me too. Here's a tiny WiX project that gives the w
I will log it as a bug.
Thanks
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Thursday, June 26, 2008 3:12 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in dark.exe?
Sounds like a bug in
Sounds like a bug in there somewhere. Can you log it?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Rerick
Sent: Wednesday, June 25, 2008 16:15
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Bug in dark.exe?
I am
I am de-compiling a MSI generated with InstallShield 11.5. I got an error
on table CustomAction.
I also found this link to the same problem:
http://www.nabble.com/--wix-Bugs-1976057---dark-fails-on-Wise-MSI-due-to-Une
xpectedColumnCount-td17552116.html
When I look at the InstallShield MSI
Adrian Lewis wrote:
Not knowingly... Okay my extension has packaged the wixlib as an embedded
resource (and the wixlib has the custom action binding - not forgetting the -bf
switch to get it included in the build) is there somewhere else in the
extension where I'm supposed to inform WiX that I
in the
extension where I'm supposed to inform WiX that I need it?Adrian "Demented
Devil" LewisIf it's ain't broke, break it THEN fix it!
> Date: Mon, 16 Jun 2008 20:51:40 -0700> From: [EMAIL PROTECTED]> To:
> wix-users@lists.sourceforge.net> Subject: Re
Demented Devil wrote:
> Now banging my head against the wall - for some reason my embedded wixlib is
> not being attached to the msi file being compiled even though my extension
> dll is being used (ie: I've got a GroupEx table in my MSI as expected but
> the custom action fragments are missing - w
Yeah I can see that! Unfortunately "creage group" functionality is just what
I need at the moment.
I've used the UtilExtension as a basis for writing my own version of Group
called GroupEx that allows for creating groups in the same way as creating
users - the code is almost a carbon copy which m
Adrian Lewis wrote:
http://schemas.microsoft.com/wix/2006/wi"; ref="Component"
/>
The last parent element (marked in bold if you're in HTML land) is missing from util.xsd
The rest of the Util extension appears to support Group nodes as children of component.
It supports it (mostly) but
Extract from util.xsd
http://schemas.microsoft.com/wix/2006/wi"; ref="Fragment"
/>
http://schemas.microsoft.com/wix/2006/wi"; ref="Module" />
http://schemas.microsoft.com/wix/2006/wi"; ref="Product"
/>
http://schemas.microsoft.com/wix/2006/wi";
ref="Component" />
The last parent eleme
PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Simon
Dahlbacka
Sent: Friday, June 13, 2008 1:09 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug with WIX 3.0.2925 installation
3.0.2925 is way old, from before VS 2008 was released. Use a newer version
from
3.0.2925 is way old, from before VS 2008 was released. Use a newer version
from http://wix.sf.net/releases/ and it will work
regards,
Simon
On Fri, Jun 13, 2008 at 12:44 AM, Mark Stega <[EMAIL PROTECTED]>
wrote:
> On attempting to install Wix 3.0.2925 I receive an error message "Votive,
> the W
On attempting to install Wix 3.0.2925 I receive an error message "Votive,
the WiX project and editor package for Visual Studio cannot be installed
because Visual Studio Standard Edition or higher is not installed". When I
acknowledge that message it appears that WiX is installed.
I have Visual
Neil Enns wrote:
> Yes, that's what our dev told me.
>
OK, definitely file a bug then. I haven't seen one on it.
--
sig://boB
http://joyofsetup.com/
-
Check out the new SourceForge.net Marketplace.
It's the best place
Yes, that's what our dev told me.
Neil
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Bob Arnson [EMAIL
PROTECTED]
Sent: Tuesday, June 10, 2008 4:55 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug
Neil Enns wrote:
> But what does that have to do with the command-line passed to NGEN?
>
Um, sorry, re-read your message. You're saying without /AppBase, NGen
fails with a syntax error?
--
sig://boB
http://joyofsetup.com/
---
: Re: [WiX-users] Bug with NetFx:NativeImage?
Neil Enns wrote:
> For EXE assemblies, this attribute does not need to be set because NGen will
> use the directory of the assembly file by default.
>
> However, we've found this is not the case and if we don't specify it the
&g
Neil Enns wrote:
> For EXE assemblies, this attribute does not need to be set because NGen will
> use the directory of the assembly file by default.
>
> However, we've found this is not the case and if we don't specify it the
> command line passed to NGen is incorrect and NGening fails.
>
I t
The documentation for NetFx:NativeImage states that setting the
AppBaseDirectory property is optional on executables:
For EXE assemblies, this attribute does not need to be set because NGen will
use the directory of the assembly file by default.
However, we've found this is not the case and if
Steffen Guhlemann wrote:
version 3.0.4123 introduced a bug with missing dlls.
The problem is that we downgraded the version of mergemod.dll. See
http://www.joyofsetup.com/2008/05/27/the-case-of-the-missing-mergemoddll-in-wix-v304123/.
--
sig://boB
http://joyofsetup.com/
This should work. Can you file a bug on SourceForge for this?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hancock
(HSG)
Sent: Tuesday, November 13, 2007 7:08 AM
To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net
Subject: [WiX-devs] Bug in Wix preprocessor?
I'm gettin
I'm getting a compile error in a Wix project in the following scenario where a
.wxi include file included in another .wxi include file isn't read from a
location relative to the outside include but instead relative to the file that
included the outer include file. In other words, I've got files
You are right.
The same problem is also in WiX2.
I will add a comment to the bug.
thanks
Stefan
John Hall wrote:
>> I think I have found a bug in WiX2 (2.0.5805.0) (not sure
>> if it is also in Wix3 - not using it)
>>
>> Consider this code:
>>
>>
>> > Checksum="yes" />
>> > CompanionFil
> I think I have found a bug in WiX2 (2.0.5805.0) (not sure
> if it is also in Wix3 - not using it)
>
> Consider this code:
>
>
>Checksum="yes" />
>CompanionFile="File1"/>
>
>
> Checking the MSI file with ORCA the FileTable:
> The row that belongs to file File2 will contain the real
Hi
I think I have found a bug in WiX2 (2.0.5805.0) (not sure if it is
also in Wix3 - not using it)
Consider this code:
Checking the MSI file with ORCA the FileTable:
The row that belongs to file File2 will contain the real version of
the file (in Column Version) instead of text: "File1
I'm working in Wix v3, and I've got a conditional component that is supposed to
install a certificate when the property CERTIFICATEPATH is set, but I'm running
into problems because InstallCertificates seems to be called regardless of
whether the component with the certificate is installed. Inst
Totally agree. Can you make sure abug is open to track the issue.
From: Cullen Waters
Sent: Tuesday, February 13, 2007 10:43 AM
To: Rob Mensching; WiX-users@lists.sourceforge.net
Subject: RE: [WiX-users] ?Bug? in linker
We've found a workaround for now, so it's not a critical issue f
We've found a workaround for now, so it's not a critical issue for us, but
something that probably should be fixed.
From: Rob Mensching
Sent: Tuesday, February 13, 2007 10:37 AM
To: Cullen Waters; WiX-users@lists.sourceforge.net
Subject: RE: [WiX-users] ?Bug? in linker
That sounds li
ence. Since we build to a 'Target' directory,
that path is invalid when the wixlib is compiled.
From: Rob Mensching
Sent: Tuesday, February 13, 2007 10:26 AM
To: Cullen Waters; WiX-users@lists.sourceforge.net
Subject: RE: [WiX-users] ?Bug? in linker
No, .wixlibs are designed to be portab
a 'Target' directory,
that path is invalid when the wixlib is compiled.
From: Rob Mensching
Sent: Tuesday, February 13, 2007 10:26 AM
To: Cullen Waters; WiX-users@lists.sourceforge.net
Subject: RE: [WiX-users] ?Bug? in linker
No, .wixlibs are designed to be portable. There was actual
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cullen Waters
Sent: Tuesday, February 13, 2007 10:05 AM
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] ?Bug? in linker
In my application, we have several wixlibs that we use to wrap functionality
for Custom Actions. Recentl
In my application, we have several wixlibs that we use to wrap functionality
for Custom Actions. Recently, we changed the way we were building these
slightly, and it broke our build.
Previously, we were relying on a particular environment variable to be set, in
order for the build to work. Th
Bertan Aygun wrote:
I followed instructions on
http://www.wixwiki.com/index.php?title=WixUI_Advanced to setup my wxs
file and I was using a per user installation by default.
As I mentioned in the bug, WixUI_Advanced was built with grand goals but
as of right now, its only tested use is fo
This bug opened yesterday since the installer I created using WiX v3.0.2420 and
WixUI_Advanced library didn't uninstall correctly.
I followed instructions on
http://www.wixwiki.com/index.php?title=WixUI_Advanced to setup my wxs file and
I was using a per user installation by default. In both ca
Torsten Rudnick wrote:
> The localization variable !(loc.MaintenanceTypeDlgRepairDisabledText) is
> unknown. Please ensure the variable is defined.
> The localization variable !(loc.MaintenanceTypeDlgRemoveDisabledText) is
> unknown. Please ensure the variable is defined.
>
> These errors occur
I use WiX v3.0.2211.0 and tried to update to v3.0.2315.0. But all
versions above my current one throwing the following errors while using
the Mondo-Dialogs.
The errors are:
The localization variable !(loc.MaintenanceTypeDlgRepairDisabledText) is
unknown. Please ensure the variable is defined.
Kirill Kovalenko
Product Manager
Softerra LLC
http://www.softerra.com
http://www.ldapadministrator.com
-Original Message-
From: Mike Dimmick [mailto:[EMAIL PROTECTED]
Sent: Monday, October 09, 2006 6:05 PM
To: Kirill Kovalenko; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] bug
Hello,
It seems I have found a bug in Tallow.exe. When it comes to generating multi
string attributes I get something like this:
Original ATL registry script is:
ldapcom.LDAPTypeValue = s 'LDAPTypeValue Class'
{
CLSID = s '{9C072A86-626E-4796-A5CF-40129EBE28FD}'
CurVer = s 'lda
appens if it is.
Out of curiosity, why are you using a subkey rather than a named value?
--
Mike Dimmick
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kirill
Kovalenko
Sent: 09 October 2006 15:36
To: wix-users@lists.sourceforge.net
Subject: [WiX-use
questions.
David Adams
MSN MessengerID: [EMAIL PROTECTED]
>From: "Emma Hanna" <[EMAIL PROTECTED]>
>To: "david adams"
><[EMAIL PROTECTED]>,
>Subject: RE: [WiX-users] [Bug #1498645 ] Configure IIS error
>on2.0.4126(Verbose Output)
>Date: Wed, 20 Se
Subject: Re: [WiX-users] [Bug #1498645 ] Configure IIS error
on2.0.4126(Verbose Output)
Matthew:
Did you have an IP address attribute originally? In my case, all of our
elements have an IP address attribute. We had to do this because we are
creating multiple web site / web application entries in IIS
nulewicz" <[EMAIL PROTECTED]>
>To:
>Subject: Re: [WiX-users] [Bug #1498645 ] Configure IIS error on
>2.0.4126(Verbose Output)
>Date: Thu, 31 Aug 2006 19:05:01 -0700
>MIME-Version: 1.0
>Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by
>bay0-mc2-f12
t machine. I'm really not an expert on the IIS stuff so I'll have
>to defer to someone more knowledgeable. One thing you can do to make this
>easier to debug is get a verbose installation log and post the lines of the
>failure (and around it) here.
>
>Derek
>
>-----Origina
tion ended 10:29:29: ConfigureIIs. Return value 3.
Action ended 10:29:29: INSTALL. Return value 3.
>From: "Derek Cicerone" <[EMAIL PROTECTED]>
>Reply-To: <[EMAIL PROTECTED]>
>To: "'david adams'"
><[EMAIL PROTECTED]>,
>Subject: RE: [
: Sunday, August 20, 2006 6:09 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] [Bug #1498645 ] Configure IIS error on 2.0.4126
It sounded like the same symptoms.
Candle and Light process successfully, but the MSI gets a Windows Installer
Error 'Failed to read IIs Webs Ta
net
Subject: Re: [WiX-users] [Bug #1498645 ] Configure IIS error on 2.0.4126
It sounded like the same symptoms.
Candle and Light process successfully, but the MSI gets a Windows Installer
Error 'Failed to read IIs Webs Table' (the failed table read is either
'Webs' or '
apparently a missing extension.
David Adams
MSN MessengerID: [EMAIL PROTECTED]
>From: "Derek Cicerone" <[EMAIL PROTECTED]>
>Reply-To: <[EMAIL PROTECTED]>
>To: "'david adams'"
><[EMAIL PROTECTED]>,
>Subject: RE: [WiX-users] [Bug #1
users@lists.sourceforge.net
Subject: [WiX-users] [Bug #1498645 ] Configure IIS error on 2.0.4126
Does anyone know a status on this bug? I am experiencing the same problem
using
WiX v.2.0.4221.0
We moved to 4221 from 3309 (where it worked) to implement MessageQueue
functionality, but may have to revert if the
Does anyone know a status on this bug? I am experiencing the same problem
using
WiX v.2.0.4221.0
We moved to 4221 from 3309 (where it worked) to implement MessageQueue
functionality, but may have to revert if there is not a solution to this
problem.
Any ideas?
David Adams
MSN MessengerID
--Original Message-
From: Jeffrey Altman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 18, 2006 5:49 PM
To: [EMAIL PROTECTED]
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in
thename
Derek:
The value is being used at build time to
f that folder during installation.
>
> Thanks,
> Derek
>
> -Original Message-
> From: Jeffrey Altman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 18, 2006 5:00 PM
> To: [EMAIL PROTECTED]
> Cc: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users
sourceforge.net
Subject: Re: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in
thename
That is a standards Windows environment variable on 64-bit Windows
builds within the WOW64 environment.
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW
006 4:36 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in
> thename
>
> In build 2419 it was possible to evaluate the value of the environment
> variable
>
> CommonProgramFiles(x86)
>
> within a define
-users@lists.sourceforge.net
Subject: [WiX-users] Bug in 2.0.4310.0 - environment vars with parens in
thename
In build 2419 it was possible to evaluate the value of the environment
variable
CommonProgramFiles(x86)
within a define as such
In 2.0.4310.0 this is broken as the close parens are
In build 2419 it was possible to evaluate the value of the environment
variable
CommonProgramFiles(x86)
within a define as such
In 2.0.4310.0 this is broken as the close parens are no longer matched
with the open parens.
Are there any quoting rules that can be used to make this work in th
migrating people to WiX 3.0 within the next few months –
so the inconvenience should be temporary.
Derek
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tobias Bengtsson
Sent: Wednesday, June 14, 2006
12:58 AM
To:
wix-users@lists.sourceforge.net
Subject: [WiX-users] Bug
Hi,
I just noticed what I believe is a bug with tallow, when
using tallow –reg somefile.reg and the regfile contains a empty string,
for instance “Example1”=””, tallow generates a Value=””
corresponding to the value, this however generates a “error CNDL0006 :
The Registry/@Value attribu
101 - 191 of 191 matches
Mail list logo
