Since this conversation is going nowhere (perhaps because WiX is dependent
on MSI, and MSI seems to predicate most of the limitations) I would like to
introduce a tangent: whether other install / deployment / packaging
technologies have made an impact.
How about Altiris Software Delivery Solution (now owned by Symantec)?
I don't think it has changed since mid-2005, so I'm assuming it's had almost
no beneficial effect.
_____
Ian Thomas - Perth, Australia
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Josh Rowe
Sent: Wednesday, May 14, 2008 3:59 AM
Cc: WiX Users
Subject: Re: [WiX-users] yep - back to being 100% frustrated
Scott,
I actually agree with you. Deployment SHOULD be trivial. It's usually
risky and non-trivial because people tend to write programs that require
special steps during deployment. By understanding the desired deployment
model up-front you reduce the tendency to write software that operates with
complex deployment models. If you want a deployment model that is a simple
file copy, make sure your software doesn't require any more "registration"
and "deployment" activities than simple file copies. Then, your WiX file
becomes a simple list of components and files, maybe a feature or two. On
the other hand, if your deployment steps require a lot of registration,
feature choices, etc., those facts will be apparent from the increased
complexity of the source code that represents those deployment steps. As
people modify the software, they are responsible for understanding how they
are changing the deployment model.
Every piece of software has a deployment model. Somewhere, someone had to
decide how software should be structured, how third party products integrate
with a parent product, etc. When the base platform you are installing onto
requires complicated deployment steps, I guess you're just screwed.
Especially when things come up like:
Icon files that are associated strictly with file extensions or CLSIDs can
have any extension, such as .ico. However, Icon files that are associated
with shortcuts must be in the EXE binary format and must be named such that
their extension matches the extension of the target. The shortcut will not
work if this rule is not followed. For example, if a shortcut is to point to
a resource having the key file Red.bar, then the icon file must also have
the extension .bar. Multiple icons can be stuffed into the same icon file as
long as all of the target files have the same extension.
I assume this is the madness you were referring to. Probably, this has more
to do with how explorer works than with how MSI works, I don't really know.
I do think that it is pathetic to not consider a technology for the
development of an application because you can't write the installer for it.
But instead of blaming WiX or MSI, I blame the author of the technology. If
the developer of that technology made good decisions about how to deploy
software that uses that technology, you wouldn't be forced into making those
hard choices. For example, if COM+ registration was as simple as copying a
.xml file to a specific directory, deployment of COM+ applications would be
simple and none of us would be moaning about it. But the authors of the
COM+ technology didn't consider how its clients would actually go about
deploying a COM+ application or a whole suite of COM+ applications.
Therefore, COM+ deployment sucks because MS didn't come up with a good story
for it, not because MSI or WiX didn't handle it.
This begs me to ask: why does the installer suck when people just wrote bad
software? If all software followed simple file-based deployment models,
would MSI still suck? I'm not sure that it would. If explorer shortcut
files didn't use some crappy proprietary format would they be nearly as
difficult to get installed? Probably not. But the explorer team didn't
consider how deployments should work when writing explorer. Of course,
hindsight is always 20/20, and it's really only recently that people are
really paying much attention to deployment of software as compared to
authoring it in the first place.
For your own software: learn from MS's mistakes and don't write it the same
way.
jmr
No virus found in this incoming message.
Checked by AVG.
Version: 8.0.100 / Virus Database: 269.23.16/1431 - Release Date: 5/13/2008
7:55 PM
BEGIN:VCARD
VERSION:2.1
N:Personal;ILT
FN:ILT Personal ([EMAIL PROTECTED])
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20070620T050625Z
END:VCARD
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
