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
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
>
12 matches
Mail list logo
