Some of this is probably about ownership. The COM+, IIS, Visual Studio teams
own the deployment/configuration for COM+, IIS, C++ redist and so on. It's
these teams that need poking to provide infrastructure that integrates with
MSI. Similarly, when the MMC team provides managed code classes to install MMC
plugins it's the MMC team that needs to be told to provide a MSI-friendly way
to install snap-ins, not the MSI team.
I'm not boggled that they provided the single transaction install. Unlike other
areas, this is one that they do really own and can do something about. Also, it
is true that more and more enterprises (including Microsoft) are unhappy with
the idea of providing one monolithic MSI (that's the one MSI=one product
assumption), and sometimes this is due to organizational boundaries where each
group owns their own MSI and they want to keep it that way for testing and
maintenance, but marketing wants the result to look like a single product in
some way. So making a series of MSIs into one transaction seems worthy to me.
What's missing is an actual chainer that provides one UI (instead of one per
MSI) and the infrastructure to deal with FilesInUse during the subsequent
silent installs, reboots etc.
Phil Wilson
From: Brian Rogers [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 20, 2008 9:51 AM
To: Bob Arnson
Cc: Wilson, Phil; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Need a custom action with UAC elevated privileges
before InstallInitialize
I have seen these types of tools used in the past. Mainly for database
migrations and other more challenging configurations. I would agree that it
would be best to have tool that ran after the installer or invoked at stages
during the installation as the user. At that point the Windows Installer server
really just becomes a bootstrapper for tools that work better. It acts like
nothing more then a sequencing and file copy device which is how some people
are using it now. I understand that Windows Installer offers some features that
would be hard to do on your own (upgrades, rollbacks, etc.).
Where I am at a loss is, over the years, these are some of the skimpy
configuration options MSI offers:
1. Registry
2. INI
3. Services (weakly)
4. COM+ (very, very weakly)
I really think the push should be back on the Windows Installer team.
Technology has changed, they need to change with it. Advanced installations
will just continue to get more complex. Why I went with WIX over other
companies such as InstallShield was for these reasons.
1. Better COM+
2. Better XML config
3. Better IIS config
4. Cheap (nothing is free as we need to support it if unable to get a fix soon
enough)
But there still needs to be work on most of these features (no offense meant AT
ALL, what is there is great!). What about truly returning a machine to clean on
an uninstall. Why can't we write to a reserved location of the installed MSI
database to keep our configuration changes on the machine instead of going nuts
on the registry? Why, after all these years, do they still not support COM+,
XML, IIS or invoking COM (MS has or makes the technology for all of these). Why
can't we have better UI? Why isn't there an easy way to do data manipulation
for text (string values)? How about some Regex? How about multiple codepages
per package? Don't get me wrong, GUIDs are great for component association, but
isn't there something else that could be used so managing patches and
automation was a bit more simple? How about just allowing for a hash value or
string of n length so that, we the developers, can control how the key will be
updated when we need to change it? If you are going to break component rules,
you will more then likely do it with or without GUIDs. I see their use for
product, package, upgrade, etc codes...
Overall, it just boggles my mind that they give us "chaining" in 4.5 and we are
supposed to jump up and down! There are still huge time problems with large
installations. You need to change the database schema in order to support more
than, what, 32K files? 2GB+ installs can take hours when all you are doing is
coping down files. The Vista UAC prompt should happen when the MSI starts for
MSI's that have defined they will need it. This comes into play when the
installation takes a long time and the users leaves the machine for a while.
Some users don't know to wait for UAC prompt and it will timeout and kill the
install. Leaving things in a bad state. An MSI is basically a database, why not
use it like one instead of writing stuff into the registry?
Please don't mistake the fact that I like using Windows Installer as a tool, I
just think it needs to become more robust at this point. Installation is
challenging, no doubt about it. But it seems like using MSI can make mountains
out of ant hills at times. With all the additional tools and custom actions
that have been written to fit into Windows Installer, more then likely the
community could have just rewritten the engine from ground up by now. I have
seen installers written using NAnt, batch, VBScript and more that can be more
effective but I have stuck with MSI.
That's my 2 cents...
--
Brian Rogers
"Intelligence removes complexity." - BR
http://www.codeplex.com/wixml/
On Tue, Feb 19, 2008 at 10:27 PM, Bob Arnson <[EMAIL PROTECTED]<mailto:[EMAIL
PROTECTED]>> wrote:
Wilson, Phil wrote:
Hear Hear! Many (if not most) install issues come from complicating an install
with configuration tasks. It's nearly always easier and cheaper to have
configuration using programs that run in a normal user environment and can be
debugged and tested without having to wait for a working setup.
And it simplifies setup development, so you can have a working setup faster.
(Day One, anyone?)
--
sig://boB
http://joyofsetup.com/
-------------------------------------------------------------------------
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<mailto:WiX-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wix-users
-------------------------------------------------------------------------
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
