Very good points. I use the bootstrapper approach along with AppSearch and
custom logic to make sure that the dependencies are still available during
subsequent transactions. While MSI 4.5 should do a better job of addressing
the cross-package dependencies issue, the MSI team has expressed no interest
in providing MC CA support in future releases. Personally I feel that this is
a huge mistake on their part and I know I'm not alone in thinking this. The
.NET Framework is simply too important and powerful to be ignored. The aging
( yet important ) MSI api/service should play well ith .NET or it risks being
rendered to the heap of legacy one day.
[EMAIL PROTECTED] wrote:
v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);}
st1\:*{behavior:url(#default#ieooui) } Thanks for the
clarification. (As I have mentioned previously on this list, I personally do my
best to steer clear from *all* non Microsoft Custom Actions and was unaware of
the special CustomActionData property.)
I would agree that unless you are familiar with the quirks C# is much easier
to write in. (In fact its what I use every day, and what I would probably use
for preference in most situations). Perhaps it is a case of group-think, to say
avoid managed code custom actions, but I understand the reasons behind it
having suffered (long before Windows Installer or the .NET framework came
along) with a scenario where an update to a third party product rendered ours
impossible to uninstall or update. Had there not been the dependency *during
the installation* on a third party component shared by both products then
fixing things would have been much easier.
Of course, many choices made when creating an installation can vary depending
on the customer(s) you are developing for. If it is an in-house product, or one
sold into a situation where good software management is in place, and you know
that a specific version of the framework will be present then by all means use
managed code custom actions. Similarly if you use a bootstrapper which makes
sure the correct framework version is present and being used it is much less
likely that you will have problems.
As with all best practices, as long as you understand the potential risks
it may sometimes be more appropriate to choose not to follow them to the
letter. The main reason for reiterating the group-think is to try and help
others not to fall into the same type of nightmare scenario I have experienced
in the past.
Personally, I hope that MS eventually sorts out the problems with managed
code custom actions and makes this discussion irrelevant.
Regards,
Richard
---------------------------------
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher
Painter
Sent: Thursday, August 02, 2007 10:32 AM
To: Foster, Richard - PAL; [EMAIL PROTECTED]; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] FW: passing parameters through custom actions in C#
`Group Think` may agree that managed code custom actions are bad, but I
certainly don't agree. Writing CA's in C++ compared to C# frankly, is painful
at best. I've done much research in this area and while I will certainly agree
that Installer Class CA's ( InstallUtil) suck, managed code in general does not
have to suck. If adding the CA to the install in itself created the framework
dependency, I'd say that's an issue.... but many, many shops these days are
doing .NET development so the odds are the dependency is already there.
Also the CustomActionData property maps to a property of the same name as
the custom action. So if the deferred CA's name is `testing` then the
immeadiate CA should set a property called `testing`.
---------------------------------
* C O N F I D E N T I A L I T Y N O T I C E *
-----------------------------------------------------------
The content of this e-mail is intended solely for the use of the individual or
entity to whom it is addressed. If you have received this communication in
error, be aware that forwarding it, copying it, or in any way disclosing its
content to any other person, is strictly prohibited. Quixote Traffic
Corporation is neither liable for the contents, nor for the proper, complete
and timely transmission of (the information contained in) this communication.
If you have received this communication in error, please notify the author by
replying to this e-mail immediately and delete the material from any computer.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>
http://get.splunk.com/_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
---------------------------------
Pinpoint customers who are looking for what you sell. -------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
