On 1/17/2010 8:39 PM, Cody Gibson wrote:
> Why does this wxs file work (i.e. the single file to install is installed at
> the correct location)
>
Usually, people ask why things don't work. Can you clarify what you're
asking?
--
sig://boB
http://joyofsetup.com/
---
On 1/19/2010 5:23 PM, Robert Barnes wrote:
> Which version is the fix in? Is there any info on the web about the bug?
Sorry, I don't know.
--
sig://boB
http://joyofsetup.com/
--
Throughout its 18-year history, RSA Conf
On 1/21/2010 11:51 AM, Reinier Lamers wrote:
> Now according to the WiX documentation the condition of Publish is
> "optional", but it does not say what it defaults to when it is not
> present. I assumed it would default to "1", but apparently it doesn't.
> I still don't really understand what it d
On 1/22/2010 7:42 PM, Jacques Eloff wrote:
> I just ran into a problem. I created an MSI that contains two assemblies.
> Assembly 1 targets .NET 3.5. Assembly 2 targets .NET 4.
WiX v2 doesn't target CLR v4. V3.5 does. You can try adding
supportedRuntime entries for the v4 runtime, but it hasn't b
On 1/20/2010 1:19 PM, Blair wrote:
> Wix.targets uses the $(WixTasksPath) property,
See "Integrating WiX Projects Into Daily Builds" in WiX.chm for more info.
--
sig://boB
http://joyofsetup.com/
--
Throughout its 18-ye
So that means that MsiConfigureFeature will just run the installation
again regardless of input parameters. That also means, that it will
attempt to install mainApp along with the addOn (if conditions are
met)... and that's what i don't want to. Installation of mainApp is very
complex and requi
I think I see what is going on. A level of "0" disables the feature. A
condition could be used to change the level, but conditions are NOT
evaluated when the ADDLOCAL (or any one of several other) property is set.
As a result, the ADDLOCAL is unable to enable that feature.
You need to change the l
This is build 3.5.1322.0 that it errors in, it also errors in 3.5.1315.0 but
the version prior to that is fine (I found it in my recycle bin, so I can
compile again now). I'll open a bug then.
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: 23 January 2010 20:1
I'm a little confused. What version of the WiX toolset are you seeing this
problem in? If it is the latest build of WiX v3.5, please open a bug because
heat should never generate a Directory/@Name=".."
On Sat, Jan 23, 2010 at 11:24 AM, Ryan O'Neill wrote:
> Getting;
>
> Error 2
That does sound very much like the behavior described here:
http://blogs.msdn.com/pmarcu/archive/2009/05/19/wix-removing-files-with-patches.aspx
On Sat, Jan 23, 2010 at 5:12 AM, Tony Juricic wrote:
> I think that now I understand what happened.
> My expectation about patching system behavior when
Getting;
Error 2 The Directory/@Name attribute's value, '..', is
not a valid long name because it contains illegal characters. Legal long
names contain no more than 260 characters and must contain at least one
non-period character. Any character except for the follow may be use
After i execute function
MsiConfigureFeature("PRODUCT-GUID", "addOnTool", INSTALLSTATE_LOCAL);
i've found following lines in log related to addOnTool:
Command Line: ADDLOCAL=addOnTool CURRENTDIRECTORY=...
...
PROPERTY CHANGE: Adding ADDLOCAL property. Its value is 'addOnTool'.
...
Feature: addOn
I think that now I understand what happened.
My expectation about patching system behavior when component is transitive was
wrong.
During patch application, transitive component condition gets evaluated and, if
it has changed from true to false, component gets deleted. However, to
facilitate pat
13 matches
Mail list logo
