That is why I said "without knowing/considering" J
As far as why people need it, it probably make things easier for people
using managed code in their product. Since I don't use managed custom
actions, I cannot justify it, but I think there are a lot of people out
there who would benefit from it. Whether it is feasible or not, that is
another question. Questions below are for CLR/Windows team perhaps, If the
problem is in loading and unloading CLR, why it was never fixed in three
product cycles of CLR and two product cycles of OS (we are talking about
almost 10 years of OS work and 6+ years of CLR, right?)? I and perhaps
thousands of devs out there don't care for Windows Sidebar in Vista, but
would like to see a more stable, powerful, smart, and tightly integrated CLR
and Windows Installer in Vista. Considering that Windows Installer, CLR and
Windows are from same company and are tied together at OS level now in
Vista, would not it make sense to overcome some of these limitations?
I think priority is determined by customer and business needs as well
technical limitations and I am not saying that support for Managed Custom
Actions should or shouldn't be a high priority, but I don't think Windows
Installer has evolved as much as it should have been considering its
integration with the OS and part of the reason is lack of demand for new
features from customers (partially because of Custom Action workarounds).
Oh well, I will let Managed Custom Action fans speakJ
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Fredrik Grohn
Sent: Saturday, March 24, 2007 1:38 PM
To: Danish Waheed; 'John Vottero'; 'Bob Arnson'
Cc: [EMAIL PROTECTED]; 'WiX-users'
Subject: Re: [WiX-users] C# .dll
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
