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
From: Scott Palmer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 13, 2008 2:58 PM
To: Josh Rowe
Cc: WiX Users
Subject: Re: [WiX-users] yep - back to being 100% frustrated
On Tue, May 13, 2008 at 1:26 PM, Josh Rowe <[EMAIL PROTECTED]<mailto:[EMAIL
PROTECTED]>> wrote:
<snip>
The moral of the story is that deployment procedures really are part of the
source code for an application. They are also risky, so implement them first
to minimize risk.
This is the problem. Deployment SHOULD be trivial. That it is a "risky" part
is outrageous. Shouldn't the hard part be in your application's algorithms
rather than how to install it? (Your statement also ignores the fact that
there is risk in other parts of the development - should those parts also be
done first to minimize risk? :-) )
Saying it's risky is fine to justify the point that installers should be dealt
with sooner in the development process - Given the current state of installer
technology I must sadly agree. But it belittles the fact that the installer
technology sucks so bad and is the root problem that needs fixing. Am I the
only one that thinks it is somewhat pathetic to not consider a certain
technology for the development of my application because I wont' be able to
write the installer? Doesn't that just say that A: the technology to be
installed (e.g. COM+), and B: the installer technology itself (e.g. MSI) both
suck?
On a Mac you would just drag and drop the application icon. The very existence
of an installer is frowned upon for most things. Why doesn't Microsoft rip-off
that instead of the desktop eye-candy? :-)
Isn't the goal of WiX to make creating MSI easier without giving up any of it's
raw abilities? Should we really have to worry at the WiX level about naming
icon Ids with extensions that match what shortcuts that use them point to?
That is just plain dumb and WiX should deal with that behind the scenes for us.
Just like it deals with the insane requirement for 8.3 filenames (WiX V3).
Should I have to hack the component keys when I want to use shortcuts in a
simple install for ALL_USERS? No, WiX should handle that too.
Regards,
Scott
-------------------------------------------------------------------------
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
