diff options
Diffstat (limited to 'src/samples/Dtf/Documents/Guide/Content/installutil.htm')
| -rw-r--r-- | src/samples/Dtf/Documents/Guide/Content/installutil.htm | 94 |
1 files changed, 94 insertions, 0 deletions
diff --git a/src/samples/Dtf/Documents/Guide/Content/installutil.htm b/src/samples/Dtf/Documents/Guide/Content/installutil.htm new file mode 100644 index 00000000..e235a7b6 --- /dev/null +++ b/src/samples/Dtf/Documents/Guide/Content/installutil.htm | |||
| @@ -0,0 +1,94 @@ | |||
| 1 | <html xmlns="http://www.w3.org/1999/xhtml"> | ||
| 2 | <head> | ||
| 3 | <title>About InstallUtil</title> | ||
| 4 | <link rel="stylesheet" type="text/css" href="../styles/presentation.css" /> | ||
| 5 | <link rel="stylesheet" type="text/css" href="ms-help://Hx/HxRuntime/HxLink.css" /> | ||
| 6 | </head> | ||
| 7 | |||
| 8 | <body> | ||
| 9 | |||
| 10 | <div id="control"> | ||
| 11 | <span class="productTitle">Deployment Tools Foundation</span><br /> | ||
| 12 | <span class="topicTitle">About InstallUtil</span><br /> | ||
| 13 | <div id="toolbar"> | ||
| 14 | <span id="chickenFeet"> | ||
| 15 | <a href="using.htm">Development Guide</a> > | ||
| 16 | <a href="managedcas.htm">Managed CAs</a> > | ||
| 17 | <span class="nolink">InstallUtil</span> | ||
| 18 | </span> | ||
| 19 | </div> | ||
| 20 | </div> | ||
| 21 | <div id="main"> | ||
| 22 | <div id="header"> | ||
| 23 | </div> | ||
| 24 | <div class="summary"> | ||
| 25 | <p> | ||
| 26 | InstallUtil is often considered as another option for executing MSI custom actions | ||
| 27 | written in managed code. But in most cases it is not the best solution, for a number | ||
| 28 | of reasons.</p> | ||
| 29 | <p> | ||
| 30 | InstallUtil (in either InstallUtil.exe or InstallUtilLib.dll form) is a .NET Framework | ||
| 31 | tool for executing the System.Configuration.Installer classes that are implemented | ||
| 32 | in an assembly. That way the assembly can contain any special code required to install | ||
| 33 | itself and uninstall itself. Essentially it is the .NET replacement for COM self-registration | ||
| 34 | aka DllRegisterServer.</p> | ||
| 35 | <p> | ||
| 36 | Self-reg or System.Configuration.Installer is convenient for development use in | ||
| 37 | order to test code without creating an actual setup package, or for an IDE which | ||
| 38 | wants to generate self-installing code. But experienced setup developers and the | ||
| 39 | <a href="MSI.chm::/setup/selfreg_table.htm">Windows Installer documentation</a> | ||
| 40 | all agree that self-reg is a bad practice for a | ||
| 41 | production-quality setup. The current theory of state-of-the-art setup is that it | ||
| 42 | should be as data-driven as possible. That is, the setup package describes as fully | ||
| 43 | as possible the desired state of the system, and then the installer engine calculates | ||
| 44 | the necessary actions to install, uninstall, patch, etc.</p> | ||
| 45 | <p> | ||
| 46 | S.C.I encourages developers to write code for things such as registering services | ||
| 47 | or registering COM classes or other things which are more appropriately done using | ||
| 48 | built-in MSI functionality (the ServiceInstall and Registry tables). The Visual | ||
| 49 | Studio .NET wizards also tend to generate this kind of install code. Again, that | ||
| 50 | is nice for development but not good for real installations. You end up with similar | ||
| 51 | but slightly different code in many places for doing the same thing. And that code | ||
| 52 | is a black-box to the installer engine.</p> | ||
| 53 | <p> | ||
| 54 | An ideal MSI custom action is a logical extension of the setup engine, meaning it | ||
| 55 | is data-driven and written in a very generic way to read from existing or custom | ||
| 56 | tables in the MSI database, following a very similar pattern to the built-in actions. | ||
| 57 | This makes the CA re-usable, and makes the installation more transparent. S.C.I | ||
| 58 | custom actions invoked by InstallUtil cannot be data-driven because they don't have | ||
| 59 | full access to the install session or database. They also cannot write to the install | ||
| 60 | session's regular MSI log, but instead use a separate log which is bad for supportability.</p> | ||
| 61 | <p> | ||
| 62 | InstallUtil also requires that the assembly be installed before the CA is able to | ||
| 63 | execute. This is a problem for CAs that need to execute during the UI phase, or | ||
| 64 | gather information before installation. For that purpose MSI allows custom action | ||
| 65 | binaries to be embedded as non-installed files, but InstallUtil cannot make use | ||
| 66 | of those.</p> | ||
| 67 | <p> | ||
| 68 | Custom actions developed with DTF have none of the limitations of InstallUtil, | ||
| 69 | giving a setup developer full capabilities to write well-designed custom actions, | ||
| 70 | only now in managed code. | ||
| 71 | </p> | ||
| 72 | |||
| 73 | <p> </p> | ||
| 74 | </div> | ||
| 75 | |||
| 76 | <div id="footer"> | ||
| 77 | <p /> | ||
| 78 | Send comments on this topic to <a id="HT_MailLink" href="mailto:wix-users%40lists.sourceforge.net?Subject=Deployment Tools Foundation Documentation"> | ||
| 79 | wix-users@lists.sourceforge.net</a> | ||
| 80 | |||
| 81 | <script type="text/javascript"> | ||
| 82 | var HT_mailLink = document.getElementById("HT_MailLink"); | ||
| 83 | var HT_mailLinkText = HT_mailLink.innerHTML; | ||
| 84 | HT_mailLink.href += ": " + document.title; | ||
| 85 | HT_mailLink.innerHTML = HT_mailLinkText; | ||
| 86 | </script> | ||
| 87 | |||
| 88 | <p /> | ||
| 89 | |||
| 90 | </div> | ||
| 91 | </div> | ||
| 92 | |||
| 93 | </body> | ||
| 94 | </html> | ||