Asp.Net2.0编译模式

Asp.Net2.0的编译模式和1.1相比改变了好多

ASP.NET 2.0 为 Web 应用程序提供三种不同的编译模型：

•	普通 (ASP.NET 1.x) — 在一个普通的 ASP.NET Web 应用程序中，代码隐藏文件被编译到一个程序集并存储在 /bin 目录中。根据要求编译 Web 页 (ASPX)。该模型对大多数 Web 站点都运行得不错。但是，编译过程使得第一次请求 ASP.NET 页时的速度比随后的请求速度缓慢。ASP.NET 2.0 继续支持这种编译模型。
•	部署预编译 — ASP.NET 2.0 的一种新功能，允许在部署前对项目进行完整编译。在完整编译中，所有的代码隐藏文件、ASPX 页面、HTML、图形资源以及其他的后端代码都被编译到一个或多个可执行程序集中，这取决于应用程序的大小和编译设置。这些程序集包含所有的已编译 Web 站点代码，而资源文件和配置文件被复制，没有做修改。这种编译方法以牺牲修改部署后 Web 站点的能力为代价，提供了最好的性能和安全性。如果您使用高可见或高安全的 Web 站点，这种选项是最终部署的最好选择。但是，如果您正在构建一个运行局部 Intranet 的小站点，并且更改站点非常频繁，那么完整预编译可能有点过分。
•	ASP.NET 2.0 编译模型也允许预编译应用程序的所有代码隐藏文件并且仍可以更新代码。可以将代码隐藏文件和原始的 .ASPX 文件（都是局部类）编译到一个预编译类中（页面的基类）。如果选择在运行时编辑 .ASPX 文件，只需重新编译页面即可。
•	完整的运行时编译 — 在部署预编译的另一个极端，ASP.NET 2.0 提供一种在运行时编译整个应用程序的新机制。也就是说，可以将未编译的代码隐藏文件和其他相关的代码放在 \app_code 目录中，并让 ASP.NET 2.0 创建并维护对程序集的引用，这些引用将在运行时根据这些文件生成。这种选项以在服务器上存储未编译代 ASP.NET 2.0 为 Web 应用程序提供三种不同的编译模型： • 普通 (ASP.NET 1.x) — 在一个普通的 ASP.NET Web 应用程序中，代码隐藏文件被编译到一个程序集并存储在 /bin 目录中。根据要求编译 Web 页 (ASPX)。该模型对大多数 Web 站点都运行得不错。但是，编译过程使得第一次请求 ASP.NET 页时的速度比随后的请求速度缓慢。ASP.NET 2.0 继续支持这种编译模型。 • 部署预编译 — ASP.NET 2.0 的一种新功能，允许在部署前对项目进行完整编译。在完整编译中，所有的代码隐藏文件、ASPX 页面、HTML、图形资源以及其他的后端代码都被编译到一个或多个可执行程序集中，这取决于应用程序的大小和编译设置。这些程序集包含所有的已编译 Web 站点代码，而资源文件和配置文件被复制，没有做修改。这种编译方法以牺牲修改部署后 Web 站点的能力为代价，提供了最好的性能和安全性。如果您使用高可见或高安全的 Web 站点，这种选项是最终部署的最好选择。但是，如果您正在构建一个运行局部 Intranet 的小站点，并且更改站点非常频繁，那么完整预编译可能有点过分。 • ASP.NET 2.0 编译模型也允许预编译应用程序的所有代码隐藏文件并且仍可以更新代码。可以将代码隐藏文件和原始的 .ASPX 文件（都是局部类）编译到一个预编译类中（页面的基类）。如果选择在运行时编辑 .ASPX 文件，只需重新编译页面即可。 • 完整的运行时编译 — 在部署预编译的另一个极端，ASP.NET 2.0 提供一种在运行时编译整个应用程序的新机制。也就是说，可以将未编译的代码隐藏文件和其他相关的代码放在 \app_code 目录中，并让 ASP.NET 2.0 创建并维护对程序集的引用，这些引用将在运行时根据这些文件生成。这种选项以在服务器上存储未编译代码为代价，在更改 Web 站点内容方面提供了最大的灵活性。 选择最佳的编译选项要由具体的情况和需要决定，但编译模型要有灵活性。即使选择使用 \app_code 目录来存储代码隐藏文件，您仍可以使用完整的编译方法来部署应用程序。 码为代价，在更改 Web 站点内容方面提供了最大的灵活性。 批编译 在 ASP.NET 2.0 中，可以利用单个 URL 请求来批编译任何应用程序。如同 ASP.NET 1.x 一样，批编译消除了第一次页面请求的延时，但造成了更长的启动周期。另外，批编译还要求在部署前编译代码隐藏文件。 Web.config 批编译设置在 ASP.NET 2.0 中仍起作用。批编译的优点是，第一个用户可以立即使用页面，而且在批编译期间可以检测到 ASPX 页中的任何错误。但是，批编译的确增加了应用程序启动的延时，并且必须要内置在 Web.config 文件中。应当注意，如果某个文件出现了问题，则该批将不会接收它。 部署预编译 部署预编译允许创建一个或多个程序集，这些程序集是 Web 站点的可执行版本。所获得的程序集包含 Web 站点的已编译代码。HTML 页面、资源、配置文件和 ASPX 页面被单独复制。 部署预编译要求使用一个称为 ASPnet_compiler.exe 的命令行实用程序。该实用程序创建一个目标部署目录，该目录包含一个含有程序集的 /bin 目录和各种 ASPX 页的 stub 文件。该实用程序还用来在原地进行预编译，类似于调用“魔术页”的行为。stub 文件共享 ASPX 页的名称，但是包含调用已编译程序集的简单代码。换句话说，ASPX 页只是空壳而不是填满的功能页。 通过为部署预编译 Web 站点，您可以获得增强的安全性，因为只有进行反编译程序集才能访问您的代码。为了增强保护，可以弄乱所得到的程序集，使您的 Web 应用程序更加安全。部署预编译的主要缺点是，在部署前必须执行这些步骤，并且在部署后不能更改 Web 站点。如果想进行更改，就必须重新编译该 Web 站点并重新部署它。 对于大多数主要的 Web 应用程序，部署预编译选项将是部署的首选机制，因为它减少了在 Web 服务器上部署的原始代码数量，并提供了最佳的安全性。这个增加的进程可以内置于通常的开发/测试/部署周期中，而工作效率并不会有多大损失。 完整的运行时编译（\app_code 目录） 在目前描述的所有三种编译方法中，在部署前必须要编译所有的代码文件（代码隐藏类和支持类）。在 ASP.NET 2.0 中，您有代码目录。 \app_code 目录是一个保存未编译类的特殊目录。在运行时，ASP.NET 运行库将该目录中的内容编译到一个程序集中，应用程序中的 ASPX 页自动引用该程序集。换句话说，通过使用代码目录，可以避免为支持代码创建和引用单独的程序集。代码目录的优点在于，不用完整编译项目就可以部署，因此减少了不匹配的可能。缺点是，有可能在服务器上公开未编译的代码。 该选项最适合于不需要大量支持代码（以代码隐藏文件的形式或外部对象的形式）的 ASP.NET 应用程序。对于一个简单的应用程序，与更为健壮的编译方法相比，快速部署和测试系统的功能提供了几个优点。

选择最佳的编译选项要由具体的情况和需要决定，但编译模型要有灵活性。即使选择使用 \app_code 目录来存储代码隐藏文件，您仍可以使用完整的编译方法来部署应用程序。

 

转载于:https://www.cnblogs.com/zqs/archive/2006/01/19/320174.html