home *** CD-ROM | disk | FTP | other *** search
/ io Programmo 40 / IOPROG_40.ISO / SOFT / NETFrameworkSDK.exe / comsdk.cab / samples.exe / QuickStart / aspplus / doc / deployment.aspx < prev    next >
Encoding:
Text File  |  2000-06-08  |  10.5 KB  |  230 lines
  1. <%@ Register TagPrefix="Acme" TagName="SourceRef" Src="/quickstart/util/SrcRef.aspx"%>
  2.  
  3. <!-- #include virtual="/quickstart/aspplus/include/header.inc" -->
  4.  
  5. <h4>Deploying ASP+ Applications</h4>
  6.  
  7. <div class="indent" style="font-family:Verdana; font-size:8pt;">
  8.     <b> <img align="middle" src="/quickstart/images/bullet.gif">  </b>
  9.     <a class="toc2" target="content" href="#fslayout">File System Layout of ASP+ Applications</a><br>
  10.     <b> <img align="middle" src="/quickstart/images/bullet.gif">  </b>
  11.     <a class="toc2" target="content" href="#resolvingassemblies">Resolving Class References to Assemblies</a><br>
  12.     <b> <img align="middle" src="/quickstart/images/bullet.gif">  </b>
  13.     <a class="toc2" target="content" href="#startup">ASP+ Application Startup and Class Resolution</a><br>
  14.     <b> <img align="middle" src="/quickstart/images/bullet.gif">  </b>
  15.     <a class="toc2" target="content" href="#codereplacement">Code Replacement</a><br>
  16. </div>
  17.  
  18.  
  19. <p>
  20. <hr>
  21.  
  22.  
  23.  
  24. <!--BEGIN SUB SECTION-->
  25. <a name="fslayout">
  26. <span class="subhead">File System Layout of ASP+ Applications</span>
  27. <p>
  28. ASP+ can be used to host multiple web applications - each identified using a unique
  29. URL prefix within a web site (where a "web site" is represented on a webserver as a
  30. unique HostName/Port combination). For example, a single Microsoft Internet Information 
  31. Server (IIS) web server with two mapped IP addresses (one aliased to "www.msn.com" and
  32. the other to "intranet") and three logical sites (http://intranet, http://www.msn.com,
  33. http://ww.msn.com port 81) could expose the following six ASP+ Applications:
  34. <p>
  35. <div class="indent">
  36. <table class="table2" cellpadding="3" width="450">
  37. <tr>    <th>Application URL</th>    
  38.         <th>Description</th></tr>
  39. <tr>    <td>http://intranet</td>    
  40.         <td>"Root" application on intranet site</td></tr>
  41. <tr>    <td>http://www.msn.com</td>    
  42.         <td>"Root" application on www.msn.com site</td></tr>
  43. <tr>    <td>http://www.msn.com:81</td>    
  44.         <td>"Root" application on www.msn.com port 81 site</td></tr>
  45. <tr>    <td>http://intranet/training</td>    
  46.         <td>"Training" application on intranet site</td></tr>
  47. <tr>    <td>http://intranet/hr</td>    
  48.         <td>"HR" application on intranet site</td></tr>
  49. <tr>    <td>http://intranet/hr/compensation/</td>    
  50.         <td>"Compensation" application on intranet site</td></tr>
  51. </table>
  52. </div>
  53. <p>
  54.  
  55. <b>Note:</b> The URL for the "Compensation Application" above is rooted within the
  56. "HR Application" URL namespace.  This URL hierarchy notation does not imply that the
  57. "Compensation App" is contained or nested within the "HR Application".  Each application
  58. instead maintains an independent set of configuration and class-resolution properties 
  59. - both are logical peer children of the "intranet" site.
  60.  
  61. <p>
  62. Each ASP+ application exposed within a URL namespace is backed using a file system
  63. directory located on either a local or remote file share.  There is no requirement
  64. for application directories to be centrally located within a contiguous part of the
  65. file system (they can be scattered throughout a disk). For example, the ASP+ Application 
  66. listed above could be located in the following different directories:
  67. <p>
  68.  
  69. <div class="indent">
  70. <table class="table2" cellpadding="3" width="450">
  71. <tr>  <th>Application URL</th>
  72.       <th>Physical Path</th></tr>
  73. <tr>  <td>http://intranet</td>
  74.       <td>c:\inetpub\wwwroot</td></tr>
  75. <tr>  <td>http://www.msn.com</td>
  76.       <td>c:\inetpub\msnroot</td></tr>
  77. <tr>  <td>http://www.msn.com:81</td>
  78.       <td>d:\msnroot81</td></tr>
  79. <tr>  <td>http://intranet/training</td>
  80.       <td>d:\serverapps\trainingapp</td></tr>
  81. <tr>  <td>http://intranet/hr</td>
  82.       <td>\\billg42\sillystuff\reviews</td></tr>
  83. <tr>  <td>http://intranet/hr/compensation/</td>
  84.       <td>c:\inetpub\wwwroot\compensation</td></tr>
  85. </table>
  86. </div>
  87.  
  88.  
  89.  
  90. <!--BEGIN SUB SECTION-->
  91. <br>
  92. <a name="resolvingassemblies">
  93. <br>
  94. <span class="subhead">Resolving Class References to Assemblies</span>
  95. <p>
  96. Assemblies are the unit of class deployment in the NGWS runtime. Developers writing
  97. NGWS classes using Visual Studio 7.0 will produce a new assembly with each
  98. Visual Studio project they compile.  Although it is possible to have an assembly
  99. span multiple Portable Executable (PE) files (ie: several module DLLs), 
  100. Microsoft Visual Studio version 7.0 (VS7) will by default 
  101. compile all assembly code into a single DLL (1 VS7 Project = 1 NGWS Assembly = 1 Physical DLL).
  102.  
  103. <p>
  104. An assembly can be used on a computer by deploying it into an assembly cache.
  105. The assembly cache can either be global to a computer or local to a particular
  106. application. It is expected that only code intended to be shared across multiple
  107. applications will be placed in the global system assembly cache. Code specific
  108. to a particular application (for example: most web application logic) will most
  109. likely be deployed in the application's local assembly cache. One nice advantage
  110. of deploying an assembly within an application's local assembly cache is that only
  111. code within that application can access it (a nice feature for scenarios involving
  112. ISPs). It also facilitates side-by-side versioning of the same application (since
  113. classes are private to each application version instance).
  114. <p>
  115. An assembly can be deployed into an  application's local assembly cache by simply copying,
  116. xcopying, or FTPing the the appropriate file(s) into a directory that has been marked as an 
  117. "assembly cache location" for that particular application. No additional registration
  118. utility needs to be run once the appropriate files are copied and no reboot is necessary. 
  119. This removes the headaches required today to deploy classic COM components within ASP applications
  120. (an administrator currently has to log onto the web server locally and run regsrv32).
  121. <p>
  122. By default, an ASP+ application is automatically configured to use the "bin" sub-directory
  123. located immediately under the application root as its local assembly cache. The bin directory
  124. is also configured to deny any browser access - so that a remote client cannot download
  125. and steal the code.  For example, the following might be the directory layout for an ASP+ application,
  126. where the /bin directory is immediately under the application root:
  127.  
  128. <div class="code"><xmp>
  129. C:\inetpub\wwwroot
  130.    Web.cfg
  131.    Default.aspx
  132.  
  133.    \bin                  <= Application Assembly Cache Directory
  134.       MyPages.dll
  135.       MyBizLogic.dll
  136.  
  137.    \order
  138.       SubmitOrder.aspx
  139.       OrderFailed.aspx
  140.  
  141.       \img
  142.          HappyFace.gif
  143. </xmp></div>
  144.  
  145.  
  146. <!--BEGIN SUB SECTION-->
  147. <a name="startup">
  148. <span class="subhead">ASP+ Application Startup and Class Resolution</span>
  149. <p>
  150. ASP+ Applications are lazily constructed the first time a client requests a URL
  151. resource from them. Each ASP+ Application is launched within a unique Application
  152. Domain (AppDomain) - a new NGWS runtime construct that enables process hosts to provide extensive 
  153. code/security/configuration isolation at runtime.
  154. <p>
  155. ASP+ is responsible for manually creating an application-domain when a new application
  156. is started. As part of this process, ASP+ provides configuration settings for the NGWS runtime
  157. to use. These include:
  158. <ul>
  159. <li>The directory paths that makeup the local assembly cache (Note: it is the NGWS 
  160. Application-Domain isolation architecture that allows each application to maintain its
  161. own local assembly cache).
  162. <li>The security restrictions of the application (what can the application access on the system).
  163. </ul>
  164. <p>
  165.  
  166. Because ASP+ does not have any compile-time knowledge of the applications developers will
  167. write on top of it, it cannot utilize static references to resolve and reference application code.
  168. Instead, ASP+ must utilize a dynamic class/assembly resolution approach to make the "initial hop"
  169. from the ASP+ Runtime into application code.  
  170. <p>
  171. ASP+ configuration and page activation files will enable developers to dynamically reference 
  172. a target compiled NGWS class to run by specifying an assembly and class name combination.  
  173. The string format for this union follows the pattern: 
  174. <p>
  175. <div class="code">assemblyname#classname</div>
  176. <p>
  177. The NGWS runtime can then use this simple string reference to resolve and load the appropriate class.
  178.  
  179.  
  180.  
  181. <!--BEGIN SUB SECTION-->
  182. <br>
  183. <a name="codereplacement">
  184. <br>
  185. <span class="subhead">Code Replacement</span>
  186. <p>
  187. NGWS Assemblies are typically compiled and deployed into a Windows DLL-based
  188. PE format. When the NGWS runtime's loader resolves a class implemented within this type
  189. of assembly, it calls the Windows LoadLibrary routine on the file (which locks
  190. its access on disk), and then maps the appropriate code data into memory for
  191. runtime execution. Once loaded, the DLL file will remain locked on disk until
  192. the Application-Domain referencing it is either torn-down or manually recycled.
  193.  
  194. <p>
  195. Although ASP+ cannot prevent the NGWS runtime from locking a loaded assembly DLL on disk, 
  196. it can support developers by ensuring that the physical DLLs
  197. they place into an web application's private assembly cache are never actually
  198. loaded by the runtime. Instead, shadow copies of the assembly DLLs are made immediately
  199. prior to their use. These shadow assemblies - and not the original files - are then
  200. locked and loaded by the runtime.  
  201.  
  202. <p>
  203. Because the original assembly files always remain unlocked, developers and 
  204. administrators are free to delete/replace/rename them without cycling the web server
  205. or having to use a special tool. FTP and similar methods work just fine. ASP+ maintains an
  206. active list of all assemblies loaded within a particular application's application domain
  207. and uses file-change monitoring code to watch for any updates to the original files. 
  208.  
  209.  
  210.  
  211. <h4>Section Summary</h4>
  212. <ol>
  213. <li>ASP+ applications are identified by a unique URL and live in the file system of
  214. the web server.
  215. <li>ASP+ can use shared assemblies, which reside in the global cache, and 
  216. application-specific assemblies, which reside in the "bin" directory of the application's
  217. virtual root.
  218. <li>ASP+ applications run in the context of AppDomains, which provide isolation and 
  219. enforcement of security restrictions.
  220. <li>Classes can be dynamically referenced via "assemblyname#classname".
  221. <li>ASP+ uses shadow-copies of assembly files to avoid locking and monitors the files,
  222. so that changes are picked up immediately.
  223. </ol>
  224. <p>
  225.  
  226.  
  227. <!-- #include virtual="/quickstart/include/footer.inc" -->
  228.  
  229.  
  230. <!-- #include virtual="/quickstart/aspplus/include/footer.inc" -->