How can I SILENTLY, without any messages can interrupt an installation from its CustomActions dll written on c#?
A:
Christopher Painter
2010-07-16 20:38:53
I'm not using WIX. Just a simple setup project.
Ike
2010-07-19 13:48:03
DTF is only a part of WiX. It encapsulates managed custom actions so that they appear as unmanaged C++ custom actions to the windows installer. This allows them to be consumed using a variety of MSI authoring tools such as Visual Studio Deployment Projects and InstallShield projects.You are currently using InstallUtil Managed Custom Actions and VDPROJ installers. I really suggest that you reconsider those choices. You might get away with the limited capabilities of VDPROJ but InstallUtil must go.
Christopher Painter
2010-07-19 16:12:23
@Christopher - I thought using any managed custom actions was a bad idea, because environments may have a different version of the runtime? So, is generating the Custom Actions using the Votice Visual Studio add-in supported, I believe that also wraps the custom actions so they are called from unmanaged code.
fletcher
2010-07-21 16:23:18
In a nutshell it's InstallUtil managed custom actions that are bad. DTF managed custom actions are fine in that they solve many of the problems that Installer class / InstallUtil custom actions created. Caveat- This is provided that you otherwise follow custom action best practices. Don't reinvent the wheel, keep declarative through use of custom tables and be transactional whenever possible.
Christopher Painter
2010-07-21 19:17:31
I try to do everything using the features provided by WiX, I find that writing the rollback and uninstallation behaviour into CAs makes me avoid them wherever possible. We tend to need to maintain state somewhat between installations, whether it is keeping config files or active directory groups that have been configured around, which, in turn, makes for several different paths of execution for our custom actions. It's usually the need to create groups in the active directory that makes me resort to writing a custom action function. (I meant to say Votive in the previous comment!)
fletcher
2010-07-22 05:07:37
I agree. I use stand actions ( built-in windows installer behavior ) whenever possible. After that I use quasi-standard actions ( vendor provided custom action patterns.. WiX, InstallShield ). Next I roll my own data driven custom actions and on the rare occasion I slam in a one-off simple custom action to do a specific purpose.
Christopher Painter
2010-07-22 12:48:29
But all of that has to do with custom action theory, not to do with technology details such as C++, EXE, J/VBSCript, or Managed C#/VB.Net via various hosting intefaces ( COMVisible COM activation via script, InstallScript CoCreateObjectDotNet, InstallShield Managed CA, InstallUtil or DTF SfxCA ).
Christopher Painter
2010-07-22 12:49:40