Well I guess my last observation is not correct when I both delete the cabs
folder and the bin and obj folders. The property in an imported target is
used by msbuild launched on the command line to build a project (without
defining the properties using the /p switch).
--
View this message in co
I do not think that the files were different, since I did a "debug" build,
and then a "release" build as soon as the debug build was finished (without
any change to the source tree). Even though the Release build was set to
use high compression, it reused the cab file (when the path is set to a
co
On 31-Oct-14 18:48, Phill Hogland wrote:
> The cause of the problem detailed in this thread is that I had defined a
> single cab cache path without considering either $(Configuration) or
> $(Platform). The fact that a different compression level was specified than
> the cached cab file was ignored
Based on the following document (and probably other pots to the forum, long
ago) I had implemented cab reuse.
http://wixtoolset.org/documentation/manual/v3/howtos/general/optimizing_builds.html
The cause of the problem detailed in this thread is that I had defined a
single cab cache path without c
I did a little more research into this observation (that using -dcl:none and
-dcl:high (or low, or no switch) all produces the exact same size output
files (msi and related external cab files)). Since these experments were in
part prompted by reading Bob's blog and the dev's discussions
(http://ww
Depending on the contents of the files you are compressing the gains from
higher compression are variable. IE, if you are deploying a bunch of text
content, then you will have a noticeable difference between no compression and
high compression. If on the other hand you are deploying data files
; Email Disclaimer
>
> -Original Message-
> From: Alec Taylor [mailto:alec.tayl...@gmail.com]
> Sent: 18 January 2011 15:26
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] compression
>
> Aye, LZMA is much better [see my thread on MakeMSI&
ark, Glasgow G20 0SP Email Disclaimer
>
> -Original Message-
> From: Alec Taylor [mailto:alec.tayl...@gmail.com]
> Sent: 18 January 2011 12:04
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] compression
>
> Why isn't there a &q
gt; Email Disclaimer
>
> -Original Message-
> From: Alec Taylor [mailto:alec.tayl...@gmail.com]
> Sent: 18 January 2011 12:04
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] compression
>
> Why isn't there a "
Registered in Scotland No. SC151456
Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20
0SP
Email Disclaimer
-Original Message-
From: Alec Taylor [mailto:alec.tayl...@gmail.com]
Sent: 18 January 2011 12:04
To: General discussion for Windows Installer XML too
Why isn't there a "best" setting?
Like with NSIS; one which tries each one and gives you the best compression =]
On Mon, Jan 17, 2011 at 9:31 PM, Pally Sandher wrote:
> Try CompressionLevel="high" as it's better than "mszip" in my
> experience.
>
> Also your MSI itself will be a significant par
Try CompressionLevel="high" as it's better than "mszip" in my
experience.
Also your MSI itself will be a significant part of that 4.5 depending on
it's complexity. Build with EmbedCab="no" to see what size it is itself.
Palbinder Sandher
Software Deployment & IT Administrator
T: +44 (0) 141 945
MSZIP is not DEFLATE (the compression algorithm used by .zip files). You
might play with the other options to see what works best.
Compression is very dependent on the input.
On Sun, Jan 16, 2011 at 6:30 PM, Ralph Esslinger <
reesslin...@matthews.com.au> wrote:
> I have created a msi file and it
10/09, Blair wrote:
> From: Blair
> Subject: RE: [WiX-users] Compression in a Merge Module
> To: "'General discussion for Windows Installer XML toolset.'"
> , chr...@deploymentengineering.com
> Date: Thursday, September 10, 2009, 2:08 AM
> If you are supplying
ssion for Windows Installer XML toolset.';
> chr...@deploymentengineering.com
> Betreff: Re: [WiX-users] Compression in a Merge Module
>
> If you are supplying both the tool and the framework MSI, why
> don't you just
> go "wix-all-the-way" and do this:
>
&
1:29 PM
To: chr...@deploymentengineering.com; General discussion for Windows
Installer XML toolset.
Subject: Re: [WiX-users] Compression in a Merge Module
Hi Christopher,
sorry for the late reply.
The setup is for a group of product catalogues (databases) that are issued
by several manufacturers. The files are dif
oolset.
> Betreff: Re: [WiX-users] Compression in a Merge Module
>
> I'm curious why you do it this way. InstallShield has
> Product Configurations and Release Flags that would alow you
> to build MSI's in various ways to address the variation
> points you desc
ias wrote:
> From: Reuss, Matthias
> Subject: Re: [WiX-users] Compression in a Merge Module
> To: "General discussion for Windows Installer XML toolset."
>
> Date: Tuesday, September 8, 2009, 4:57 AM
> Thanks for your response.
>
> I may have started to han
toolset.
> Betreff: Re: [WiX-users] Compression in a Merge Module
>
> As you say the Module element doesn't seem to have the Media child
> element
> (http://wix.sourceforge.net/manual-wix3/wix_xsd_module.htm) but
> it doesn't really matter. When the merge module is cons
As you say the Module element doesn't seem to have the Media child
element (http://wix.sourceforge.net/manual-wix3/wix_xsd_module.htm) but
it doesn't really matter. When the merge module is consumed into an MSI
its files will be compressed into the media table of the MSI and
therefore use the same
Riyaz Mogharabin wrote:
> I've heard that putting the files in more than one cabinet can be helpful.
> Is that right? And how much does it help?
>
http://www.joyofsetup.com/2008/03/29/wix-performance-tip-use-multiple-cabinets/
--
sig://boB
http://joyofsetup.com/
---
My install Pack is about 600 MB in size, and there is no limitation in it's
size. I'm using the MSZIP compression level, and it's ok for me. The only
concern, is the time it takes to create the MSI file.
It takes over 90 minutes after the light is commanded to build the MSI. I
know that this proc
On 10 May 2009, at 19:37, Chuck wrote:
> Chris Ridd wrote:
>> Yes, the higher compression levels make building the msi much slower.
>> If you've got the concept of a "debug" vs "release" build, I'd
>> suggest
>> using no compression when debugging, and high when doing a release.
>
> In the inte
Another thing to keep in mind is that file types do affect the speed of
compression. Do some testing along those lines if you have larger builds.
Our team has seen up to 1 1/2 hours come off our cabbing times.
Brian Rogers
"Intelligence removes complexity." - Me
http://icumove.spaces.live.com
On
Chris Ridd wrote:
> Yes, the higher compression levels make building the msi much slower.
> If you've got the concept of a "debug" vs "release" build, I'd suggest
> using no compression when debugging, and high when doing a release.
In the interest of science I ran through the compression levels o
On 10 May 2009, at 13:38, Riyaz Mogharabin wrote:
> Dear All,
>
> You know we have 5 compression levels:
>
> None, High, Low, MSZIP and medium.
>
> Is it possible to use a third party compression code, such as 7-up
> or rar?
>
> And if it is possible, does it help to have faster and better
>
26 matches
Mail list logo
