What I don't understand is why people are so eager to build managed custom
actions in the first place. I don't know for sure, but I don't think there are
quite as many threads over at the device driver lists about managed device
drivers... The only reason to use managed code from inside a custom action is
because you need to configure something that does not have a native
configuration interface. But that is really a problem with that product in that
case - not with the Windows Installer.
The biggest problem with managed custom actions I think is that prior to Vista
the CLR is not a native component of the operating system. The second biggest
problem I think is that once one version of the CLR has been loaded into a
process it permanently pollutes that process and even if it can be unloaded it
can never be loaded back in again, making it impossible to load a different
version at a later point. It is a complex thing to implement and compared to
other things probably not a very high priority.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Danish Waheed
Sent: Saturday, March 24, 2007 9:15 PM
To: 'John Vottero'; 'Bob Arnson'
Cc: [EMAIL PROTECTED]; 'WiX-users'
Subject: Re: [WiX-users] C# .dll
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
