@joebigelow / wix
Code Commits Issues Pulls Sessions CI/CD
main
main
htm 74 lines 4.13 KB
Raw
1 <!doctype HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
2 <html>
3 <head>
4 <title>Proxy Class for Managed Custom Actions</title>
5 <meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
6 <link rel="stylesheet" type="text/css" href="MSDN.css">
7 </head>
8 <body id="bodyID" class="dtBODY">
9 <div id="nsbanner">
10 <div id="bannerrow1">
11 <table class="bannerparthead" cellspacing="0" id="Table1">
12 <tr id="hdr">
13 <td class="runninghead">Managed Libraries for Windows Installer</td>
14 <td class="product"></td>
15 </tr>
16 </table>
17 </div>
18 <div id="TitleRow">
19 <h1 class="dtH1">Proxy for Managed Custom Actions</h1>
20 </div>
21 </div>
22 <div id="nstext">
23 <p>The custom action proxy allows an MSI developer to write
24 custom actions in managed code, while maintaing all the advantages of type 1
25 DLL custom actions including full access to installer state, properties,
26 and the session database.</p>
27 <p>There are generally four problems that needed to be
28 solved in order to create a type 1 custom action in managed code:</p>
29 <ol>
30 <li><p><strong>Exporting the CA function as a native entry point callable by
31 MSI:</strong> The Windows Installer engine expects to call a LoadLibrary and
32 GetProcAddress on the custom action DLL, so an unmanaged DLL needs to implement
33 the function that is initially called by MSI and ultimately returns the result.
34 This function acts as a proxy to relay the custom action call into the
35 managed custom action assembly, and relay the result back to the caller. </p>
36 <li><strong>Providing supporting assemblies without
37 requiring them to be installed as files:</strong> If a DLL custom
38 action runs before the product's files are installed, then it is difficult
39 to provide any supporting files, because of the way the CA DLL is singly
40 extracted and executed from a temp file. (This can be a problem for
41 unmanaged CAs as well.) With managed custom actions we have already hit
42 that problem since both the CA assembly and the MSI wrapper assembly
43 need to be loaded. To solve this, the proxy DLL carries an appended
44 cab package. When invoked, it will extract all contents of the
45 cab package to a temporary working directory. This way the cab package can
46 carry any arbitrary dependencies the custom action may require.</li>
47 <li><p><strong>Hosting and configuring the Common Language Runtime:</strong>
48 In order to invoke a method in a managed assembly from a previously
49 unmanaged process, the CLR needs to be "hosted". This involves choosing
50 the correct version of the .NET Framework to use out of the available
51 version(s) on the system, binding that version to the current process, and
52 configuring it to load assemblies from the temporary working directory.</p>
53 <li><p><strong>Converting the integer session handle into a
54 Session object:</strong> The <a href="">Session</a> class in the managed
55 wrapper library has a constructor which takes an integer session handle as
56 its parameter. So the proxy simply instantiates this object before
57 calling the real CA function.</p>
58 </ol>
59 <p>The unmanaged CAPack module, when used in combination with the managed proxy in
60 the
61 Microsoft.WindowsInstaller assembly, accomplishes the tasks above to enable
62 fully-functional managed DLL custom actions.</p>
63 <p><br/></p>
64 <p><b>See also:</b></p>
65 <ul>
66 <li><a href="writingcas.htm">Writing Managed Custom Actions</a></li>
67 <li><a href="caconfig.htm">Writing the CustomAction.config file</a></li>
68 <li><a href="samplecas.htm">Sample C# Custom Actions</a></li>
69 <li><a href="buildingcas.htm">Building Managed Custom Actions</a></li>
70 </ul>
71 <p><br/></p>
72 </div>
73 </body>
74 </html>