In my Custom BA I noticed a weird change:
In PlanPackageBegin:
Debugging shows that myAction has the value Cache. Seems to be an enum
bug.
--
View this message in context:
We would need the Burn log from %TEMP% to be able to diagnose this.
On Mon, Jun 29, 2015 at 3:49 AM, js69 juergen.schaep...@sirona.com wrote:
In my Custom BA I noticed a weird change:
In PlanPackageBegin:
Debugging shows that myAction has the value Cache. Seems to be an enum
bug.
I have a bundle (built with v3.9) with a custom managed BA with 3 packages in
the Chain- what the packages contain is not important so let's call them
PackageA, PackageB and PackageC.
I install v1 of my bundle, which installs v1 of each package.
I then start an upgrade to v2. It upgrades PackageA
: June-08-14 10:37 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Bug in torch - wixmst output is not in XML format
On 6/8/2014 11:13 AM, Tunney, Stephen wrote:
Re: [WiX-users] Bug in torch - wixmst output is not in XML format
-xo doesn't produce a text file if there are files
On 6/9/2014 9:06 AM, Tunney, Stephen wrote:
It might be a case of The Mondays but I'm at a loss at what you are getting
at :( What are these other files that might get output by torch? How can I
supress their output?
Rename the .wixmst to .cab and open it in explorer. You'll see binaries
OK. That's kinda cool, now how do I stop it from outputting that? :)
From: Bob Arnson [b...@joyofsetup.com]
Sent: June 9, 2014 6:24 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Bug in torch - wixmst output is not in XML format
On 6/9
Hey everyone,
I've got the following command line for torch after applying melt to a
WiX-built MSI. It is a fairly large MSI (500 megs with cabs embedded).
Starting 'C:\Program Files (x86)\WiX Toolset v3.8\bin\torch.exe -nologo -p -xo
-xi
On 6/8/2014 11:13 AM, Tunney, Stephen wrote:
Re: [WiX-users] Bug in torch - wixmst output is not in XML format
-xo doesn't produce a text file if there are files in the output (which
is pretty often).
--
sig://boB
http://joyofsetup.com
Hello,
I have a big problem with W2008 R2:
The menu shortcuts aren't removed after uninstalling my aplication ... but
...
If I uninstall the same .msi with Windows7, ALL the shortcuts are correctly
removed, so the aplication is unistalled correctly. I'm using Wix3.8.
Is this a bug or a problem
Is the same user installing and uninstalling? Do you have uninstall logs?
-Original Message-
From: BGINFO4X [mailto:bginf...@kztsoftware.com]
Sent: Thursday, October 24, 2013 10:23 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Bug or wxs problem
and uninstalling? Do you have uninstall logs?
-Original Message-
From: BGINFO4X [mailto:bginf...@kztsoftware.com]
Sent: Thursday, October 24, 2013 10:23 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Bug or wxs problem?
Hello,
I have a big problem
Hi all,
I created a custom dialog...
I have a button control that is disabled/enabled whether or not some text
box controls are empty or have some text in them:
Condition Action=disable/Condition
Condition Action=enable/Condition
Here is one of my text box controls:
Control
sigh my original msg is missing text:
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bug-Disable-a-control-because-another-control-is-empty-enter-text-control-is-not-enabled-tp7581117p7581118.html
Sent from the wix-users
/Condition
Condition
Action=enableDATABASE_WINDOWSAUTHENTICATION=0/Condition
/Control
-Original Message-
From: StevenOgilvie [mailto:sogil...@msn.com]
Sent: October-04-12 10:40 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Bug? Disable a control because another
[mailto:steven.ogil...@titus.com]
Sent: Thursday, October 04, 2012 9:44 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug? Disable a control because another control is
empty, enter text control is not enabled
Sorry, lets try that again:
Control Id
I was able to specify a component with an empty guid
Component Id=SilverlightXap Guid=
The installer compiled, linked, ran. The reason I found this problem was that
when I went to uninstall the product it left the silverlight xap file the
component was needing to uninstall.
Thanks!!!
Allan
...@pointsolutionsllc.com]
Sent: Wednesday, September 26, 2012 12:51 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Bug?
I was able to specify a component with an empty guid
Component Id=SilverlightXap Guid=
The installer compiled, linked, ran. The reason I found this problem
That is exactly how you specify an unmanaged Component.
On Wed, Sep 26, 2012 at 10:50 AM, Allan Edwards
allan.edwa...@pointsolutionsllc.com wrote:
I was able to specify a component with an empty guid
Component Id=SilverlightXap Guid=
The installer compiled, linked, ran. The reason I found
1. Agreed. I find it easier to change UpgradeCodes, rather than do the
UpgradeVersion dance. In my mind, I think about UpgradeCodes as defining
whether the package installs SxS or not.
2. You can override the default planning of Burn for packages by returning
your requested state for that
Or use MajorUpgrade element. smile/
On Wed, Jul 11, 2012 at 12:36 PM, Don Walker don.wal...@versaterm.comwrote:
Chad Petersen wrote
I was able to get past this error in your example by adding this inside
the Fragment
InstallExecuteSequence
RemoveExistingProducts
Rob Mensching-7 wrote
Or use MajorUpgrade element. smile/
I don't think that the MajorUpgrade element gives me the flexibility that I
need. My assumptions (and what I believe to be best practice) are:
1. The UpgradeCode is fixed for all versions of the product.
2. The Product Id is set to
Don Walker wrote
Here is the situation:
1. We allow multiple versions of our product to be installed at the same
time if they have a different Major.Minor version. I don't believe that
the MajorUpgrade element supports this option. The UpgradeVersion elements
shown should provide for
In WiX version 3.6.3109.0 I am getting the following build error:
Product.wxs(16,0): error LGHT0094: Unresolved reference to symbol
'WixAction:InstallExecuteSequence/RemoveExistingProducts' in section
'Product:*'.
The same error appears for line 18.
My test example follows:
?xml version=1.0
, 2012 8:49 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Bug? UpgradeVersion element causing LGHT0094 error
In WiX version 3.6.3109.0 I am getting the following build error:
Product.wxs(16,0): error LGHT0094: Unresolved reference to symbol
'WixAction:InstallExecuteSequence
Chad Petersen wrote
I was able to get past this error in your example by adding this inside
the Fragment
InstallExecuteSequence
RemoveExistingProducts After=InstallInitialize /
/InstallExecuteSequence
Scheduling RemoveExistingProducts worked for me too. Ironically, I had just
Hi Focks:
I think I've found a bug in wix 3.6:
I'm trying to create a solution that allows building two msi's one x86 and one
x64.
I have to following in my package element to this end:
Package
InstallerVersion=300
Compressed=yes
InstallScope=perMachine
Use the arch switch on the candle coomand-line and remove the Platform
attribute.
On Fri, Apr 27, 2012 at 5:10 AM, Sean Farrow
sean.far...@seanfarrow.co.ukwrote:
Hi Focks:
I think I've found a bug in wix 3.6:
I'm trying to create a solution that allows building two msi's one x86 and
one x64.
Is there a way to specify that in visual studio?
Cheers
Sean.
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: 27 April 2012 15:37
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] bug in wix 3.6?
Use the arch switch
April 2012 15:37
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] bug in wix 3.6?
Use the arch switch on the candle coomand-line and remove the Platform
attribute.
On Fri, Apr 27, 2012 at 5:10 AM, Sean Farrow
sean.far...@seanfarrow.co.ukwrote:
Hi Focks
: [WiX-users] bug in wix 3.6?
IIRC, by default it picks it up from your VS Configuration.
On Fri, Apr 27, 2012 at 9:04 AM, Sean Farrow
sean.far...@seanfarrow.co.ukwrote:
Is there a way to specify that in visual studio?
Cheers
Sean.
-Original Message-
From: Rob Mensching [mailto:r
for Windows Installer XML toolset.
Subject: Re: [WiX-users] bug in wix 3.6?
So if I have a solution that has an x64 platform, and don't include a
platform attribute, would this work?
Cheers
Sean.
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: 27 April 2012 17:12
: [WiX-users] bug in wix 3.6?
IIRC, by default it picks it up from your VS Configuration.
On Fri, Apr 27, 2012 at 9:04 AM, Sean Farrow
sean.far...@seanfarrow.co.ukwrote:
Is there a way to specify that in visual studio?
Cheers
Sean.
-Original Message-
From: Rob Mensching
...@fiserv.com]
Sent: 27 April 2012 17:57
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] bug in wix 3.6?
Last time I looked at the WiX .targets files I noticed that they create an
InstallerPlatform property that is passed to candle. The InstallerPlatform
property
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] bug in wix 3.6?
Hi:
I am building one msi for x86, and x64 from the same project. If I am
interpreting you correctly, I can let visual studio create the new solution
platform for me.
Please correct me if I'm
toolset.
Subject: Re: [WiX-users] bug in wix 3.6?
That is correct. You will still need to build twice as only one platform gets
built at a time.
You'll want to take a look at what projects are selected for each solution
platform and make decisions about how to build your solution. Perhaps you need
XML toolset.
Subject: Re: [WiX-users] bug in wix 3.6?
Hi:
And where finally can I see what is building for what platform?
I know I can see but don't know where!
Cheers
Sean.
-Original Message-
From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
Sent: 27 April 2012
as x64 and then build my
overall solution as Mixed Platforms.
Neil
-Original Message-
From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
Sent: 27 April 2012 20:24
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] bug in wix 3.6?
Option 1
Thanks, Rob, for informing me that these NAnt tasks are going to be
deprecated. I'll stick to using the exec task from here on out.
On Sat, Apr 14, 2012 at 12:25 AM, Rob Mensching r...@robmensching.comwrote:
Sounds like a bug. I don't think many people use the NAnt tasks and we are
looking at
I think I found a bug in the NAnt task for Candle - specifically the
defines and define elements used to assign values to preprocessor
variables. If more than 1 Define element exists, only the first one
appears to be passed to Candle.
Ex: assume Wix file requires preprocessor variables
Sounds like a bug. I don't think many people use the NAnt tasks and we are
looking at removing them in future versions.
On Fri, Apr 13, 2012 at 8:43 AM, Adam Kaplan akap...@princeton.com wrote:
I think I found a bug in the NAnt task for Candle - specifically the
defines and define elements
[mailto:r...@robmensching.com]
Sent: Saturday, March 10, 2012 12:10 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug or Feature in Wix 3.6--remapping of paths to
dutil.h and renaming of dutil_2010.lib to dutil.lib
The changes are intentional to straighten out
Since I build projects that use the setupbld-style bootstrapper, and since I
have customized the setupexe project to a degree, I now have a dependency on
the directory structure of Wix 3.5 RTM. I've notice that when I switched my
Workstation to the latest version of the Wix 3.6 toolset, that
The changes are intentional to straighten out the mess of our libraries. It
was not the goal to break setupexe.
However, setupexe isn't really taken care of in WiX v3.6 since Burn
basically replaces it so it might get bounced around some.
On Fri, Mar 9, 2012 at 1:58 PM, John Cooper
toolset.
Subject: [WiX-users] Bug with Semi colon in Custom action data
Hi all,
I think this is a bug in wix :
I have a variable containing a semi colon.
From this variable and many others, I build another variable that I use as
custom action data.
Unfortunately, the custom action
Hi all,
I think this is a bug in wix :
I have a variable containing a semi colon.
From this variable and many others, I build another variable that I use as
custom action data.
Unfortunately, the custom action data is cut because of the semi-colon. If I
replace the semi-colon by a comma, it
Forgot to mention : I am using wix 3.6.
Regards,
Nicolas Penin
-Message d'origine-
De : Nicolas Penin [mailto:n.pe...@happly.fr]
Envoyé : jeudi 17 novembre 2011 17:28
À : General discussion for Windows Installer XML toolset.
Objet : [WiX-users] Bug with Semi colon in Custom action data
for Windows Installer XML toolset.
Objet : Re: [WiX-users] Bug with Semi colon in Custom action data
Forgot to mention : I am using wix 3.6.
Regards,
Nicolas Penin
-Message d'origine-
De : Nicolas Penin [mailto:n.pe...@happly.fr] Envoyé : jeudi 17 novembre 2011
17:28 À : General discussion
-to-serialize.html
From: Nicolas Penin n.pe...@happly.fr
Sent: Thursday, November 17, 2011 10:54 AM
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Bug with Semi colon in Custom action
Yeah, VS and MSBuild and Votive conspire in evil ways to prevent the value
from coming back in a way that you can edit. You can actually get into this
same situation with C# projects.
You have to edit the .wixproj (or .csproj is you mess up your C# project,
like I did once) to fix it.
On Tue,
I've got an undefined preprocessor variable in my .wxs file, but when I
entered it into the Define preprocessor variables: edit box as
var.Variable=abc it made no difference. I then tried the probably really
wrong way of
$(var.Variable)=abc
At this stage the Votive editor wouldn't let me undo
Hi,
Just tried to create in VS2010 (Ultimate) a new setup project (CTRL +
Shift +N) Windows Installer XML Setup Project OK. Afterwards I
tried to build a x64 solution with no changes to the initial WiX
source code by starting the Configuration Manager and click under
Project contexts on
Hm ok. Think this was a layer 8 problem as the Configuration Manager
seems a bit tricky in configuring. So no bug just a user problem ;-)
Thanks,
Tobias
2010/12/7 Tobias S tobias.s1...@gmail.com:
Hi,
Just tried to create in VS2010 (Ultimate) a new setup project (CTRL +
Shift +N) Windows
Hi Michael,
Thanks a lot for the explanation and for the link. I'll take a look, as
this would be the approved way of doing this.
If one wants to do that with CA, then the code would be (I'll put the
code here for further reference):
CustomAction Id=QtExecDeferred_Cmd Property=QtExecDeferred
Getting the RemoveFile table entry right is *a lot* easier than getting
rollback correct in all the cases it is required. The RemoveFoldersEx custom
action does the same sort of work in the http://wix-contrib.codeplex.comproject.
On Mon, Nov 29, 2010 at 7:02 AM, Michael Urman mur...@gmail.com
Broken Link. The correct one is http://wixcontrib.codeplex.com/
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Tuesday, November 30, 2010 9:10 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] [BUG/limitation in WIX/MSI
Absolutely; handling rollback scenarios can increase the complexity
surrounding file removal several-fold.
(But when there aren't specific timing requirements, you just run such
a delete from the commit phase.)
Given that there is no clear way to know the future upgrade paths
(does anyone ever
Hi Michael,
Thanks for your answer.
Because of this, the premise that a component condition can prevent
the RemoveFile table entry from executing during uninstall is flawed,
I wouldn't have expected that, because of:
1) The code works as expected when I have REP after installFinalize,
The trick here is that in the working case, the component is never
uninstalled. With REP after InstallFinalize, the new install
increments the component's reference count, possibly installing
updated contents. Then REP uninstalls the earlier version, which
merely decrements this component's
Hi all,
After searching any possible explanation on the internet, and after
trying any possible combination of conditions, I got to the conclusion
that this is either a bug or a limitation of Wix/MSI, because there is
no condition that could distinguish between an uninstall (from
add/remove
OK, this seems to be a MSI bug, because after investigating I noticed that:
1) by opening the created MSI with Orca I can see in the Component table:
removeFile{F82061CB-27F9-41F5-B5FE-2EDCA1F1A8F9}
INSTALLLOCATION0(REMOVE=ALL) AND (NOT UPGRADINGPRODUCTCODE)
2) The, after an
Good job isolating it, but it's a problem understanding how component
conditions work. They only serve to gate when a component is
installed. With the transitive bit set, their going false can also
cause them to be uninstalled in a minor upgrade or other maintenance
scenario. However their being
Hey Guys,
Is there any other solution to this issue ?
Thanks,
Bhaumik
On Sun, Jul 18, 2010 at 11:52 PM, Rob Mensching r...@robmensching.comwrote:
Please note that WiX v3.5 is still under development. That means it is not
necessarily perfectly stable. Expect bugs and thank you for filing this
Rob,
Thanks for getting back to me.As per previous discussions, we found about
this bug in WIX 3.5.
Is there anything that I have to do to open bug on this issue at some
specific place. So that it can be tracked..Let me know.
--
Bhaumik (GE Healthcare)
http://wix.sf.net has a link to the bug database.
On Sun, Jul 18, 2010 at 8:51 AM, Bhaumik Barot bhaumik...@gmail.com wrote:
Rob,
Thanks for getting back to me.As per previous discussions, we found about
this bug in WIX 3.5.
Is there anything that I have to do to open bug on this issue at
I have added to Bug database .I have release next week and this is higher
priority.I hope you will address the issue ASAP.
Bhaumik
On Sun, Jul 18, 2010 at 11:38 AM, Rob Mensching r...@robmensching.comwrote:
http://wix.sf.net has a link to the bug database.
On Sun, Jul 18, 2010 at 8:51 AM,
Please note that WiX v3.5 is still under development. That means it is not
necessarily perfectly stable. Expect bugs and thank you for filing this one.
On Sun, Jul 18, 2010 at 9:54 AM, Bhaumik Barot bhaumik...@gmail.com wrote:
I have added to Bug database .I have release next week and this is
...@robmensching.com]
Sent: Thursday, June 03, 2010 10:23 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in IIS:WebSite or IIS:WebAddress ?
WiX v3.5.1623.0 is pretty old when it comes to WiX v3.5 builds. There have
been a lot of IIS7 bugs going into WiX v3.5 so
I want to install a virtual dir in IIS 7, and I used IIS extension to locate an
existing website like
IIS:WebSite Id=MyWebSite Description=test
IIS:WebAddress Id=MyAddress Port=8080/
/IIS:WebSite
But I found wix also uses the Description attribute to locate the website, no
WiX v3.5.1623.0 is pretty old when it comes to WiX v3.5 builds. There have
been a lot of IIS7 bugs going into WiX v3.5 so you should stay current with
the builds if you want IIS7 support.
On Thu, Jun 3, 2010 at 1:36 AM, Chong Li chon...@microsoft.com wrote:
I want to install a virtual dir in
: [WiX-users] Bug in IIS:WebSite or IIS:WebAddress ?
WiX v3.5.1623.0 is pretty old when it comes to WiX v3.5 builds. There have been
a lot of IIS7 bugs going into WiX v3.5 so you should stay current with the
builds if you want IIS7 support.
On Thu, Jun 3, 2010 at 1:36 AM, Chong Li chon
I am attempting to build an installer with a couple of modified standard
screens in the FeatureTree UI: CustomizeDlg and WelcomeDlg. I copied the
FeatureTree UI wxs file and modified it. The CustomizeDlg screen builds
without any problems. I get an error on the WelcomeDlg - see below. I run
the
On Mon, Apr 19, 2010 at 9:48 PM, Mike Rerick mrer...@iwsinc.com wrote:
Is there a work-around I can do to get this installer to build?
[exec] light.exe : error LGHT0001 : Item has already been added. Key in
dictionary: 'MyWelcomeDlg/Title' Key being added: 'MyWelcomeDlg/Title'
Thanks Dave. I don't know why I didn't see that. I looked at it several
times.
On Mon, Apr 19, 2010 at 1:28 PM, Dave Brotherstone dav...@pobox.com wrote:
On Mon, Apr 19, 2010 at 9:48 PM, Mike Rerick mrer...@iwsinc.com wrote:
Is there a work-around I can do to get this installer to build?
Posting this in case anyone else runs into this because I'm not sure
if this is a bug or expected behaviour.
I'm updating a plug-in installer to work with a new product which will
be imminently released. After (at least) 4 years of complaining the
developers of said product have caved in
-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: 31 March 2010 11:06
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Bug with components which contain only
XMLConfigelements?
Posting this in case anyone else runs into this because I'm not sure
On 3/31/2010 6:06 AM, Pally Sandher wrote:
gives the same error (as expected). I can work around this simply by
adding a RegistryValue to each component setting it as the KeyPath for
those components but does anyone know if this is expected behaviour or a
bug with these types of components?
Rob Mensching wrote:
It has been a long time since we found a dependency between tables that
wasn't automatically added by the WiX toolset. Is it possible that a
ControlCondition table is required by the ICEs whenever there is a Dialog
table... or something screwy like that?
Apparently,
It has been a long time since we found a dependency between tables that
wasn't automatically added by the WiX toolset. Is it possible that a
ControlCondition table is required by the ICEs whenever there is a Dialog
table... or something screwy like that?
On Fri, Nov 27, 2009 at 3:41 PM, Bob
Rob Hamflett wrote:
Yes, but why? It used to work fine without it.
Did you have a ControlCondition table? The ICEs come from the MSI team
so we have to rely on the doc for the hows/whys.
--
sig://boB
http://joyofsetup.com/
Rob Hamflett wrote:
ICE17 FAILICE Internal Error 105. API Returned: 1615.
ICE17 FAILError 2228: C:\DOCUME~1\Robert\LOCALS~1\Temp\ICEA37.tmp,
ControlCondition, SELECT
`Dialog_`,`Control_` FROM `ControlCondition` WHERE `Dialog_`=? AND
`Control_`=? AND `Action`= 'Enable'
2228 is
Yes, but why? It used to work fine without it. In addition to the EndDialog
event I previously had
a Custom Action that was launched when that button was clicked. I removed the
Custom Action and the
problem started appearing. There wasn't a Condition on the Control to begin
with (although
String ID size: 2
Code page: 932
-Original Message-
From: Heath Stewart [mailto:clubs...@gmail.com]
Sent: June 4, 2009 8:43 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in Torch?
Gilad, I need the database code page. The code
size: 2
Code page: 932
-Original Message-
From: Heath Stewart [mailto:clubs...@gmail.com]
Sent: June 4, 2009 8:43 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in Torch?
Gilad, I need the database code page. The code page shown
for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in Torch?
Gilad, I need the database code page. The code page shown
there is only for the summary information stream. The
database code page can be displayed by running msiinfo */d*
*database.msi*.
On Thu, Jun 4, 2009 at 7:40
discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in Torch?
Gilad, could you detail what the database code pages are set
to? From the Windows Installer SDK, you can use msiinfo /d
*msifilename* to retrieve the database code page (note this
is not the same as the summary
discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in Torch?
Gilad, could you detail what the database code pages are set
to? From the Windows Installer SDK, you can use msiinfo /d
*msifilename* to retrieve the database code page (note this
is not the same
Hello
I was trying to create a single language msi (for English Japanese). Both
compiled successfully with candle light but I ran into the following problem
when I ran torch to get the difference between the msi files.
Running torch with the following parameters:
torch.exe -t language
Never heard of it. Can you please post a bug and include all of the
Property.idt files from the directories listed below.
Gilad Israeli wrote:
Hello
I was trying to create a single language msi (for English Japanese). Both
compiled successfully with candle light but I ran into the
Created bug # 2800797. I included all the files in the Binder Unbinder
emporary directories
-- Gilad
-Original Message-
From: Rob Mensching [mailto:r...@wixtoolset.org]
Sent: June 3, 2009 6:05 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users
: June 3, 2009 6:05 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in Torch?
Never heard of it. Can you please post a bug and include all
of the Property.idt files from the directories listed below.
Gilad Israeli wrote:
Hello
I
discussion for Windows Installer XML toolset.
Subject: [WiX-users] Bug in version # validation
I'm getting this error:
error LGHT0204: ICE61: Upgrade.VersionMax 7.0.32768.1 format is wrong
According to the doc, the Build component of version numbers can be up
to 65535. I think there's a signed
I'm getting this error:
error LGHT0204: ICE61: Upgrade.VersionMax 7.0.32768.1 format is wrong
According to the doc, the Build component of version numbers can be up
to 65535. I think there's a signed/unsigned problem with the code
validating the VersionMax field. Devs agree? I'll log a bug if
Yes, I found this bug two days ago.
-Original Message-
From: Jeremy Lew [mailto:j...@liquidmachines.com]
Sent: Friday, March 20, 2009 10:02
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Bug in version # validation
I'm getting this error:
error LGHT0204
everything from MSI... :)
-- Yan
-Original Message-
From: Yan Sklyarenko [mailto:y...@sitecore.net]
Sent: Friday, January 30, 2009 9:38 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in iis:WebApplication?
Sorry for delay with this response, Rob.
I
[mailto:rob.mensch...@microsoft.com]
Sent: Wednesday, January 28, 2009 7:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in iis:WebApplication?
It does surprise me that IIS console can configure this and the
CustomAction cannot. I wonder if this is another
discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in iis:WebApplication?
What happens if you create a medium isolated AppPool on Windows XP with
DTC disabled? Does it have issues as well or does it automatically
enable DTC? I think this is less an issue with the extension
then there is definitely a
bug to be fixed.
-Original Message-
From: Yan Sklyarenko [mailto:y...@sitecore.net]
Sent: Wednesday, January 28, 2009 01:17
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in iis:WebApplication?
What happens if you create
, 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 attention when we meet on Thursday.
-Original Message-
From: Yan Sklyarenko [mailto:y...@sitecore.net]
Sent: Tuesday, January 20, 2009
CustomActions but
sometimes things still poke through.
-Original Message-
From: Yan Sklyarenko [mailto:y...@sitecore.net]
Sent: Tuesday, January 27, 2009 03:04
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in iis:WebApplication?
I've decided to bring
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:
Component DiskId=1
1 - 100 of 177 matches
Mail list logo
