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 don’t 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
isnÂ’t on a managed network and doesnÂ’t 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 what’s available, ‘what does this do?’, so invoke
the installer almost by accident.) That comes from a corporate desire to fit
smaller, cheaper disks but thereÂ’s 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 I’m 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 weÂ’d stop
buying pre-assembled applications and instead assemble our applications
ourselves from libraries of pluggable components. (This one keeps coming
back, only now it’s 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 havenÂ’t built any installers with WiX.
Everything weÂ’re shipping weÂ’re still shipping with Visual Studio deployment
projects. I havenÂ’t 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 weÂ’re 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 weÂ’ve 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 IÂ’m 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
donÂ’t install many shared components, which in my view is the area in which
Windows Installer-compliance is necessary. IÂ’m 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 theyÂ’re so simple that
thereÂ’s no need to do component reference-counting (which is a good thing,
since thatÂ’s 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! ItÂ’s not very
compelling.
With my database administratorÂ’s hat on, I find applications that install
their own databases tiresome. They inevitably seem to make mistakes in their
installers. Reporting Services service packs donÂ’t quite line up with schema
versions, so you seem to end up scrapping the existing database and
recreating. SourceGearÂ’s Vault accidentally inserted a backslash before the
data file name when there was already one at the end of the path, then SQL
ServerÂ’s Volume Shadow Copy Writer complained when trying to back that
database up. Other tools donÂ’t 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 thatÂ’s the approach
weÂ’re 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: wix-users@lists.sourceforge.net
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
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
