Re: [WiX-users] Need a custom action with UAC elevated privileges before InstallInitialize

[Brian R. <rog...@gm...>]

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 <bo...@jo...> 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://boBhttp://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...@li...
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>