IMO, it is very easy to blame it on Windows Installer team without actually
knowing/considering the work and requests they get from so many different
teams within Microsoft, let alone third parties and without
considering/knowing the limitations they face in implementing features (be
it business or technical). I am sure they focus on customers' needs. But
do we as customers request what we need from Windows Installer team? I
think one of the problems is that we are too busy to get the installer done
right and to meet our own goals and in doing so when we encounter issues or
limitations, not all of us send out feature requests to Windows Installer
team, we simply find a workaround using Custom Actions and then forget about
it. I am surprised to see that Windows Installer is now 4.0 and if you go
through the features added since 1.0 came out (back in 1997?) there are not
too many features added in 10 years and 4 product cycles. Probably more bug
fixes than features, I might be wrong, but I think if we would have
requested more features, we would have gotten a lot better and versatile
Windows Installer than what it is today. So part of the blame goes on us
(setup developers) as well.
The limitations of Windows Installer can be overcome by having custom
actions, but custom actions cause more failures than anything else (at least
from my experience), so people see custom actions as workarounds. If
Windows Installer team ignores feature requests just because they think that
customers can write Custom Actions to get what they want, that is wrong.
So let's decide that we will always send a feature request to Windows
Installer team every time we encounter limitations. In fact we can do what
we just did, start a thread (not sure if it is appropriate to do this in wix
users list, but should be done somewhere, Windows Installer blog, or some
other place)and if people agree then we can send even more requests for the
same feature, that will definitely get their attention. For example, in the
case of managed custom actions, if we send out 10+ requests from different
people/groups for the same feature, how can they ignore so many customers?
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John Vottero
Sent: Saturday, March 24, 2007 11:54 AM
To: Bob Arnson
Cc: [EMAIL PROTECTED]; WiX-users
Subject: Re: [WiX-users] C# .dll
Bob Arnson wrote:
John Vottero wrote:
The System.Configuration.Installer base class has virtual methods for
Install, Uninstall, Commit and Rollback. Doesn't that mean that that it can
support Rollbacks?
Yes, they can. The number that do is vanishingly small. Doing it right is
hard, regardless of language. Half the time, they're not even close to
necessary: The event log stuff in InstallUtil, for example, just writes
registry keys. So you have CAs and managed CAs when a few rows in the
Registry table get it for free.
I agree that writing a good CA is hard but, I'll bet it's easier in C# than
it is in C. I also agree that eliminating a CA is the best way to make it
robust.
The PowerShell stuff is also just a bunch of registry entries (I think, it's
not documented).
I don't know enough about Windows Installer to understand all the
implications of managed CAs. What I do know is that there are many groups
at Microsoft that are creating managed CAs to support their products and
they aren't creating unmanaged CAs and they aren't documenting what their
managed CAs actually do so ISV's are left stuck in the middle. We have to
reverse engineer the Microsoft managed CAs so we can develop "proper"
installers.
The situation is clearly broken and it's up to Microsoft to fix it.
Yes and in addition to Rob's suggestion of pinging the MSI team, I'll add:
Ping the teams whose stuff you use. Let them know that blindly calling
managed code via InstallUtil isn't good enough for you. Teams like the
black-box approach because it gives them future flexibility (over, say,
documenting the registry entries their IntallUtil CAs write). Tough. Let
them know it. Document the stuff and WiX can handle them via extensions and,
when necessary, CAs.
I always try to register my concerns with the teams producing the managed
installers. The PowerShell team has said that they would document what
their managed installer does but, I haven't seen the documentation yet.
The "future flexibility" angle is my biggest worry. One of these days, some
team is going to completely scramble what their managed installer does and
they'll think that they aren't breaking anything. If they really want that
future flexibility, they have to put some pressure on the Windows Installer
team to support managed Installers.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
