On 05/06/2010 12:34, DEÃK JAHN, Gábor wrote:
> it probably slipped my attention. This is one of the areas where there must
> have been a breaking change between v2 and v3 because the samples were
> originally written in v2 times (actually working back them, as much as I can
> tell), upgraded t
x27;ve only just noticed it.
I think you are right, and that tutorial is wrong. I posted a similar
question to this group a couple of months ago...
On 15/03/2010 22:38, John Aldridge wrote:
> I'm confused about minor upgrades... the tutorial at
>
>http://www.tramontana.co.hu/wix
On 30/04/2010 19:02, wallywojo wrote:
>
> may not need anything additional, I am pretty sure that a Full MSI validation
> would report this. Have you tried to validate the built MSI?
I don't get any ICE validation errors or warnings out of the build. Is
there some other validation I could/should
I've just made a mistake like the following simplified example
This is a 64 bit installer, which needs to install both the 32 and 64
bit versions of a DLL in the respective system folders.
This all works fine until I come to do an adminis
On 14/04/2010 01:59, Bob Arnson wrote:
> Could you turn on verbose MSBuild logging and capture another failure?
> That should be good enough in a bug report to get the MSBuild/Votive
> folks on the case.
Bug ID 2987220
Thank you again.
--
Cheers,
John
--
On 03/04/2010 14:22, Bob Arnson wrote:
> On 4/1/2010 6:55 AM, John Aldridge wrote:
>> I have a Votive(MSI) project in Visual Studio which sometimes crashes
>> right at the end of the build with the traceback
>
> Try setting the RunWixToolsOutOfProc property in your .wixproj
I have a Votive(MSI) project in Visual Studio which sometimes crashes
right at the end of the build with the traceback
> Exception has been thrown by the target of an invocation.
>at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[]
> arguments, SignatureStruct& sig, Metho
On 22/03/2010 14:36, Bob Arnson wrote:
> On 3/22/2010 9:40 AM, John Aldridge wrote:
>> It looks as if the MSM is internally compressed, because its size is
>> less than that of the DLLs it contains. This has bad consequences when
>> we try to build a patch for our applicatio
As part of installing our application, we deliver a merge module (our
application includes an API, and the MSM is to enable our customers to
create a Visual Studio deployment project for an application of their
own written against our API).
It looks as if the MSM is internally compressed, becau
distribute the update as an MSP, can we?
Thank you for your help!
--
Cheers,
John
> -Original Message-
> From: John Aldridge [mailto:j...@jjdash.demon.co.uk]
> Sent: Tuesday, 16 March 2010 8:39 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: [Wi
I'm confused about minor upgrades... the tutorial at
http://www.tramontana.co.hu/wix/lesson4.php#4.1
describes how to author the WiX package, keeping the product code the
same, and including an element which insists that a previous
version of the product is installed (and that a later one isn
On 08/03/2010 13:37, Bob Arnson wrote:
> On 3/6/2010 8:22 PM, Paul Baker wrote:
>> We're now thinking of registering our COM server using RegistryValue
>> elements, where RegistryValue/@Key contains "Wow6432Node". Does anyone
>> know of any potential problems with this approach?
>
> You might want
On 13/02/2010 15:20, Bob Arnson wrote:
> On 2/12/2010 6:19 AM, John Aldridge wrote:
>> If I use WiXNetFxExtension to test for NETFRAMEWORK35, does this mean
>> "3.5 itself is installed" or "3.5 or any later version is installed"?
>
> The former but it&#x
If I use WiXNetFxExtension to test for NETFRAMEWORK35, does this mean
"3.5 itself is installed" or "3.5 or any later version is installed"?
(Pedantically, I guess I mean "3.5 or any later version which can run
applications built against .Net 3.5")
--
Cheers,
John
-
I've read
http://robmensching.com/blog/posts/2003/10/18/Component-Rules-101
and I'm still confused about something. Suppose a component gets
installed more than once, but to different places. This can happen if
several product installers include the same component (same component
GUID, containi
Genius! Thank you :)
Now, is this behaviour a bug in WiX which I ought to report? It seems
really odd that it doesn't "know" that CommonFilesFolder is
intrinsically 32 bit.
--
Cheers,
John
On 16/12/2009 00:59, Sascha Beaumont wrote:
> I think I've found a solution... wrapping the 32-bit Commo
onent of a
> 64-bit folder
>
>>
>>
>> > SourceFile="$(var.WixMergeModule1.TargetPath)" />
>>
>>
>
> Try this instead:
>
>
>
>SourceFile="$(var.WixMergeModule1.
I want to have an (x64) merge module which installs some 64 bit files to
MergeRedirectFolder, and some 32 bit files to the 32 bit
CommonFilesFolder. My (simplified) merge module wxs is...
>
> http://schemas.microsoft.com/wix/2006/wi";>
>
> Manufacturer="WixMergeModule1" InstallerV
On 10/12/2009 17:10, Rob Mensching wrote:
> Yes, there definitely is. Feel free to file a bug then use .wixlibs instead
> of Merge Modules.
>
>> On 09/12/2009 17:55, Wilson, Phil wrote:
>>> All the CommonFilesFolder values in merge modules are by convention
>> appended with a mangled guid, but as
On 09/12/2009 17:55, Wilson, Phil wrote:
> All the CommonFilesFolder values in merge modules are by convention appended
> with a mangled guid, but as far as I can tell the mechanism that rationalizes
> all the folder name properties from merge modules (such as
> CommonFilesFolder.guid) at merge
I'm getting some behaviour which surprised me... if I have the following
in a merge module
then when I build an installer using this merge module, I get a number
of messages like
light.exe(0,0): warning LGHT107
Our product has both 32 and 64 bit versions, and we want to allow users
to install these side-by-side on a 64 bit machine. The 64 bit version
includes a 32 bit component which is identical to the corresponding
component of the 32 bit version.
How should we choose an installation location for th
> From: Anthony Wieser [mailto:wix-l...@wieser-software.com]
> Sent: 28 August 2009 12:21
>
> Does anyone here know for sure if the target version of the installer
> changed to 3.00 from 2.00 for the merge modules?
I don't know whether it's changed, but I do know that on my machine with the
upda
The WiX documentation says...
> The KeyPath attribute is set to yes to tell the Windows Installer
> that this particular file should be used to determine whether the
> component is installed. When you have one file per component you
> should always set the KeyPath attribute to yes.
...but it appe
elopment, and we don't want
to dictate their choice of installer technology.
Thanks for the reply!
--
Cheers,
John
> John Aldridge wrote:
>> I have a merge module WiX project
>>
>>
>> http://schemas.microsoft.com/wix/2006/wi";>
>&g
I have a merge module WiX project
http://schemas.microsoft.com/wix/2006/wi";>
I asked...
> From: John Aldridge [mailto:j...@jjdash.demon.co.uk]
>
> Are there any guidelines for how best to create both a 32 and a 64 bit
> installer from a single WiX
> source file? I can use variable substitution to set the Platform attribute
> and pick up the right
Are there any guidelines for how best to create both a 32 and a 64 bit
installer from a single WiX source file? I can use variable substitution to set
the Platform attribute and pick up the right versions of the various executable
files, but I'm puzzled about how to manage Component GUIDs. Do th
28 matches
Mail list logo
