Windows Installer was designed to support corporate deployment of
applications to shared machines with install-on-demand and roaming profiles,
and to support Windows 95 and up. If you understand that, a lot of the
features and the ICE error reports make sense. The trouble is that this
corporate deployment environment is so rare even large corporations rarely
use it, largely because many MSIs dont work right in that environment and
so far away from the common case that most of us are dealing with, namely
installing applications one time for all users of a personal computer that
isnt on a managed network and doesnt roam.
Why is a per-user install the default? Because in these corporate
environments, multiple users on the same machine might not be allowed access
to the same applications.
Why are advertised shortcuts the default? Because in these environments, you
might advertise the product only so that only those users who actually need
to use it actually invoke the installer. (Never mind that users will
typically browse to see whats available, what does this do?, so invoke
the installer almost by accident.) That comes from a corporate desire to fit
smaller, cheaper disks but theres a lower limit as to how small you can
make a disk with a given technology. For example an 80GB Seagate SATA drive
costs £24.20 from a site Im looking at now, but a 160GB drive, double the
space, costs only £6 or 25% more. The disk as a fraction of the system cost
has fallen over the last ten years.
Why are advertised shortcuts and icons so complex? To support Windows 95 and
NT 4.0 without the IE4 Desktop Update.
Why do the Class and TypeLib (etc) tables create an advertised link? Because
someone thought it would be a good idea to support on-demand installs of COM
objects, when it was a tenet of architecture astronauts that wed stop
buying pre-assembled applications and instead assemble our applications
ourselves from libraries of pluggable components. (This one keeps coming
back, only now its called a mash-up, but everyone always overlooks the
testing matrix, which suffers combinatorial explosion with even a few
different components.)
In some cases the ICE tests indicate a smell in the core installer engine
ICE38, keying the installation of a shortcut from the absence of a
registry key, should have been fixed in Windows Installer itself somehow.
And now, time for a confession. I havent built any installers with WiX.
Everything were shipping were still shipping with Visual Studio deployment
projects. I havent been given the time to invest in improving the installer
for our application server product, which is really our only product (in
that the same object code is shipped to every customer) for which I was
evaluating WiX. (I work for a small contract development house owned by a
value-added reseller, mainly of handheld devices, but were all generalists
and do some management consoles, Web- and Windows-based, for handheld-driven
systems, plus this application server and some comms servers.) The
application server is nearly exclusively sold as part of a larger solution
while plug-in applications can be written by anyone (you write a COM object
with a couple of defined entry points), in practice weve sold to very few
companies doing their own application development. As such any investment in
the application server tends to be to fix issues experienced by one or more
customers or to add features for an upcoming system.
Having been on this mailing list for a long time Im torn between replacing
the installer for this with a WiX-based installer with a huge amount of
pain that will go with that, and the knowledge that few of my colleagues
will be able to maintain it and ditching it for something like NSIS. We
dont install many shared components, which in my view is the area in which
Windows Installer-compliance is necessary. Im considering going
registration-free COM, a tricky prospect with VB6 applications (no
investment in migrating from VB6
), but better than installing shared
components. Shared-nothing components and application initialisation of
configuration make for very simple WiX installs, but theyre so simple that
theres no need to do component reference-counting (which is a good thing,
since thats where Windows Installer is complicated) so you might as well
have used xcopy. The only thing Windows Installer is doing for you is
allowing you to create shortcuts and register services! Its not very
compelling.
With my database administrators hat on, I find applications that install
their own databases tiresome. They inevitably seem to make mistakes in their
installers. Reporting Services service packs dont quite line up with schema
versions, so you seem to end up scrapping the existing database and
recreating. SourceGears Vault accidentally inserted a backslash before the
data file name when there was already one at the end of the path, then SQL
Servers Volume Shadow Copy Writer complained when trying to back that
database up. Other tools dont give the administrator the option of where to
place the database any sensible SQL Server setup (not dedicated to a
single database) will want to place the data files on a disk separate from
any other files, and the log files on further separate disks, so the
default DB location may well not be useful. Given the amount of
flexibility required, you may well want to just supply scripts and allow the
DBA to run them after creating databases themselves, and thats the approach
were taking (the application server supports server farms with a SQL Server
database for shared state).
--
Mike Dimmick
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tanikella,
Rajanikanth (SCR US)
Sent: 16 May 2008 15:35
To: [email protected]
Subject: Re: [WiX-users] yep - back to being 100% frustrated
John McFayden does raise a good point in bringing up the perspective of the
MSI user over that of the developers. I try to believe that even
ridiculous-seeming things we encounter might actually have a very good
reason behind them if we only knew the actual requirement that they were
intended to fulfill. Yes, I know, 8.3 file names and such do not provide a
compelling example of this in 2008. But it's still more likely that there is
(or once was) a good reason for it than that there are a bunch of dunces
writing the software we depend upon. Each trade-off made was probably well
reasoned, and yet we still have MSI as we know it today. Who is to say that
we would not have made the same decision at the time?
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-users
