[转]ASP.NET的编译方法

ASP.NET的编译方法
    第一种：默认编译

默认编译就意味着无需对ASP.NET应用程序执行任何手动编译。在这种情况下ASP.NET 运行库将在Web浏览器首次请求应用程序中的页时编译web应用程序，随后服务器将编译后的结果存储到%SystemRoot%"Microsoft.NET"Framework"version"Temporary ASP.NET Files文件夹下的特殊文件夹中，随后的请求只实例化此文件夹中已经创建的DLL，该DLL发送响应请求。如果对应用程序中的文件进行了更改，则在下次请求页时，ASP.NET 运行库将确定已更改的文件的依赖项，并且仅重新编译受更改影响的文件。

优点：

1、         简单易用。部署网站时，只须将写好的网站源码复制到web服务器上就行，ASP.NET 编译器会为您完成所有工作。

2、         当预编译网站所需的额外步骤减慢了开发过程时，默认编译是开发过程中可供选择的最佳编译模型。

      缺点：

1、         首次请求网站时可能会有很大延迟。

2、         要就将源代码文件放在web服务器上。

3、         对服务器上的网站目录拥有文件系统访问权限的任何人都可以获取源代码和 UI 代码。

    疑问：

         在郝刚老师的《ASP.NET2.0开发指南》第三章，第三节：编译和运行应用程序中这样写到“默认情况下，用户首次请求资源（例如本例中的Default.aspx）时，将动态编译ASP.NET页面（Default.aspx）和代码隐藏文件（Default.aspx.cs）。在第一次编译页和代码文件之后，服务器将自动缓存编译后的结果，这样将大大提高随后对同一页提出的请求的效率”，我理解的上面这段话的意思是：用户首次请求页面a，服务器编译页面a，而不会编译页面b。这时只有页面a的请求效率得到了提高，随后用户首次请求页面b，服务器才编译页面b，这样页面b的请求效率才得到提高。而微软msdn网页上说的是“首次请求时编译web应用程序”。这点我感觉郝刚老师写错了，几次试验的结果都证明是首次请求网页就会编译整个web应用程序。       

第二种：就地预编译

 我感觉就地预编译就是手动完成了在默认预编译中的浏览器首次请求的功能，也就是用下面的命令来代替首次请求触发编译，它和默认编译的差别很小，唯一的进步就是缩短了首次请求的延迟。我们可以使用ASP.NET的编译工具（aspnet_compiler.exe）就地预编译web程序，这将编译所有的ASP.NET文件类，而其他文件，如html文件、图形和非ASP.NET静态文件将保持原状。该编译工具调用ASP.NET运行库编译网站，其逻辑形式与用户首次请求页时相同。在编译过程中，编译器将为所有可执行输出创建程序集，并将程序集存在%SystemRoot%"Microsoft.NET"Framework"version"Temporary ASP.NET Files文件夹下的特殊文件夹中，随后ASP.NET将用此文件夹中的程序集来完成页面的请求。如果对应用程序中的文件进行了更改，可以使用 ASP.NET 编译工具重新编译受影响的文件，也可以不管它，在下次向应用程序请求页时重新编译受影响的文件。

      编译方法：

1、         浏览到web站点的根目录，添加特定的程序处理precompile.axd，然后随便浏览一个页面，将页面名称改为 precompile.axd 这样我们得到一个消息说“编译已经完成”。注：这种方法我至今没有实现，看到网上一片文章说“precompile.axd和webadmin.axd在ASP.NET2.0的beta2中已经不存在”。

2、         可以选用下面的命令实现

定到%SystemRoot%"Microsoft.NET"Framework"version"

运行

aspnet_compiler -v /virtualpath

        注：virtualPath参数指示网站的 Internet 信息服务 (IIS) 虚拟路径

   aspnet_compiler –p physicalorrelativepath –v /

        注：在这种情况下，physicalOrRelativePath参数是指网站文件所在的完全限定目录路径，或者相对于当前目录的路径。-V指定要编译的应用程序的虚拟目录，如果也使用了-p参数，就使用物理路径查找应用程序的目录

用上面的方法编译后就可以在上面提到的目录里找到编译后的程序集。

       优点：

1、         缩短了网站首次请求时的响应时间

2、         无需特出步骤，将代码复制到web服务器上，运行命令就行。修改文件后，可以重新编译也可以不管。

       缺点

1、         要将源代码部署在web服务器上。

2、         对网站上的目录拥有访问权限的任何人都可以获得源代码和UI代码。

第三种：可更新UI完全预编译

通过ASP.NET编译工具（aspnet_compiler.exe）的-u开关，可以将源代码（.cs 和/或 .vb 文件以及 .resource 文件）编译为 DLL 并保留 .aspx 文件中的 UI 标记以供更新。所有的DLL都被保存在bin文件夹里，这样我们可以对网页进行有限的更新，例如：可以更改控件的颜色、字体和其他外观元素，而不用重新编译应用程序。但是如果我们改变了后台代码则需要重新编译。

 编译方法：

1、         用visual studio2005 打开web应用程序，在工具栏里找到“生成”->“发布网站”，在“发布网站”界面上选择“允许更新此预编译站点”，确定后可以在目标位置，找到编译后的web应用程序。我们看到所有的cs文件都不见了，在bin文件夹里出现了很多DLL文件。随便打开一个页面文件，里面的UI代码并没有变化，我们可以随意修改里面的代码而不用重新编译程序。

2、         运行命令

aspnet_compiler -p physicalOrRelativePath -v / targetPath-u

注：-u开关（此开关表示您想编译站点以进行部署和更新）

      优点：

1、         缩短了网站首次请求时的响应时间。

2、         用户界面开发人员无需重新编译整个网站即可修改网站的外观和行为。

3、         保护应用程序源代码中包含的知识产权，以防止被对网站目录拥有文件系统访问权限的任何人意外看到。

     缺点：

1、         在部署到成品服务器之前，需要执行单独的编译步骤。

2、         对网站目录拥有访问权限的任何人都可以获取应用程序 UI 代码（.aspx 文件）中包含的知识产权。

3、         多个页不能引用同一CodeFile类。

 第四种：不可更新UI的预编译

  当使用不可更新UI的预编译时，ASP.NET编译工具将正常情况下运行时编译的所有ASP.NET源文件编译为程序集，其中包括页中的程序代码、.cs和.vb类文件以及其它代码文件和资源文件，但是每个页面并不单独编译为一个程序集。编译器将从输出中移除所有的源代码和标记。在生成的布局中，为每个.aspx文件生成编译后的文件（扩展名为.compiled），该文件包含指向该页面程序集的指针。如果需要更改网站（包括页面布局），那么必须更改原始文件，并重新编译站点。唯一例外的是站点配置文件web.config。我们可以更改服务器上的web.config文件而不需要重新编译。

      编译方法：

aspnet_compiler -p physicalOrRelativePath -v / targetPath

            注：这里没有开关-u

      优点：

1、         缩短了网站首次请求的响应时间

2、         保护应用程序源代码和 UI 代码中包含的知识产权，以防止被对网站目录拥有访问权限的任何人意外看到。

      缺点：

1、         在部署到成品服务器以前需要单独的编译步骤。

2、         对网站的代码（包括UI代码）进行很小的改动就要重新编译整个网站。

  第五种：编译为固定名称的程序集

   在以上四种编译方法的编译工程中，编译器生成的程序集使用随机名，每次重新编译程序程序集的名称都会变。由于程序集的名会便，所以维护一个程序集就必须重新部署整个程序。使用ASP.NET编译工具的-fixednames开关，或者在visual studio 2005中的发布发布网站时选择“使用固定命名和单页程序集”，就会为程序中的每个页分别创建一个程序集，而其名称该页面的虚拟路径，如果虚拟路径长度超过windows文件命名允许的长度则使用路径的哈希值。顶层目录（app_code）中的文件编译为单个程序集。程序集的名称在后续编译时不会更改，因此可以创建只替换已更改的程序集的应用程序 Service Release

  编译方法：

1、在Visual Studio 2005中发布网站的时候选择“使用固定命名和单页程序集”。

2、aspnet_compiler -v virtualpath targetpath –fixednames

或aspnet_compiler –p physicalorrelativepath –v / targetpath –fixednames

  优点：

1、缩短网站请求时的响应时间。

2、每个程序集的名称不会随着多次编译而更改，因而无需重新部署整个应用程序即可以替换特定的程序集。

3、对应用程序的次要更新可能更具有针对性。

缺点：

1、      在部署到成品服务器以前需要单独的编译步骤。

2、      需要分别为应用程序中的每个页创建一个程序集。这可能会为包含许多页的站点创建大量程序集。

   第六种：预编译为签名的程序集

  可以使用 ASP.NET 编译工具创建可部署到服务器的全局程序集缓存 (GAC) 或应用程序的 Bin 目录中的具有强名称的程序集。使用签名的程序集使得恶意用户更难用恶意代码替换应用程序的程序集。

   每当使用-keyfile或-keycontainer开关为程序集签名时，还必须使用-aptca开关指定将allowpartiallytrustedcallersattribute属性应用于程序集。如果不指定-aptca开关，程序集就不能由 ASP.NET 进程调用，并且 Aspnet_compiler.exe 将引发异常。

   编译方法：

1、         用visual studio2005发布网站的时候选择“对预编译程序集启用强命名”，并填好秘钥文件。

2、         aspnet_compiler -v virtualpath targetpath –keyfile –keyfile.snk -aptca

如果使用秘钥容器则使用下列命令

aspnet_compiler -v virtualpath targetpath –keycontainer –keycontainer.snk -aptca
如果您的网站不是 IIS 应用程序，并因此在 IIS 元数据库中没有项，则在命令提示符处键入以下内容。

3、         aspnet_compiler -p physicalorrelativepath –v / targetpath –keyfile –keyfile.snk -aptca

如果使用秘钥容器则使用下列命令

4、         aspnet_compiler -p physicalorrelativepath –v / targetpath –keycontainer –keycontainer.snk -aptca

优点：

1、 共享开发环境中的密钥管理可能很复杂。

2、程序集必须让 ASP.NET 运行库allowpartiallytrustedcallersattribute属性