|
Preaching to the choir there, we were using an old shonky
none msi version of installshield. It clearly did less work, it's just hard
explaining that to users/support staff, when all they see is the end result.
With the previous version the guy who wrote it put a million workarounds in
there to allow our support staff to install multiple copies of the same version
of the product... Trying to explain that this is bad practice just gets me
insults. Oh well, all is well now, the performance figures have calmed people
down a little now that they realize they are complaining about
nothing.
Cheers Rob. From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: 03 August 2006 16:17 To: 'Simon Topley'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Performance issues When
you say you've replaced InstallShield with the WiX toolset, what version of
InstallShield did you replace? I ask because the non-MSI versions of
InstallShield used a scripting engine to do the install. That engine (as
I've been told) doesn't do nearly the same amount of integrity checking that the
Windows Installer does. For
example, the Windows Installer maintains a rollback script of all the files that
were replaced during the installation. Thus, if the user cancels,
everything gets put back the way it was. That adds overhead that most
installation technologies don't implement (and one of the reasons I cringe every
time I see another product released on those engines). Now,
if you were using InstallShield for Windows Installer and the package you
created with the WiX toolset was slower... well, then the WiX toolset probably
has a bug. <smile/> From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Simon
Topley Good morning to the
Brotherhood/Sisterhood, I'm sure this is a problem others have
encounted. I have now replace our suite of installsheild products with spanky
new WIX versions. I have managed to elimitnate a large amount of redundant code
(previous installers copied large amounts of file that were never used). Most of
the installers are now half the size in compressed form. Dispite this the
installation process now takes longer (so I'm told, I intend to run some
performance tests later today). Is there a standard explaination for this that I
can give to people (i.e. talk to city hall) I am playing with the idea of having internal
versions (products that will only be used by testers and support staff) as
uncompressed in the hope that most of the time is being spent extracting files.
Simon The information contained in this e-mail is
likely to be confidential and may be legally privileged. It is intended only for
the addressee. If you have received this message in error please notify the
sender immediately at the above address. The disclosure, copying or distribution
of this message or its contents without the prior approval of Wallingford
Software Ltd. is strictly prohibited. Wallingford Software Ltd. is not liable
for unauthorised disclosures nor for subsequent actions or omissions in reliance
upon them. The information contained in this e-mail is likely to be confidential and may be legally privileged. It is intended only for the addressee. If you have received this message in error please notify the sender immediately at the above address. The disclosure, copying or distribution of this message or its contents without the prior approval of Wallingford Software Ltd. is strictly prohibited. Wallingford Software Ltd. is not liable for unauthorised disclosures nor for subsequent actions or omissions in reliance upon them. |
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
