首页 > 编程 > .NET > 正文

ASP.NET中新的代码编译功能(三)

2024-07-10 12:56:15
字体:
来源:转载
供稿:网友
  • 本文来源于网页设计爱好者web开发社区http://www.html.org.cn收集整理,欢迎访问。
  • 预编译支持

    asp.net web 窗体的优势之一就是增加动态编译后,您可以很轻松地更改 .aspx 页,保存更改时页面将动态更新,而不需要重新编译(只要不使用模块化代码)。但动态编译并不是对每个应用程序都适合,而且第一次访问某个应用程序时,动态编译会导致浏览器的初始性能降低。另外,很多时候您可能希望部署一个没有源代码的应用程序。如果您遇到上述情况,您会更高兴地了解到 asp.net whidbey 具有支持预编译 web 站点的功能。asp.net whidbey 支持两种预编译模式:在位预编译和部署预编译。

    在位预编译

    在位预编译使您可以对 web 站点中的所有页面进行手动批编译。这也是用户在您的应用程序中首次单击某个页面后发生的操作(前文提到的后一种情况除外),用户只需坐下来等待批编译完成。使用在位预编译有两个主要原因:首先,它可以避免第一次请求页面时批编译的性能降低;其次,它使您可以“先于”用户发现编译错误。

    在位预编译也很容易实现,只需浏览到 web 站点的根目录,添加特定的处理程序名称 precompile.axd(熟悉 asp.net 跟踪功能的用户会发现该名称与 trace.axd 处理程序的名称类似):

    http://localhost/mywebsitename/precompile.axd


    其中 mywebsitename 是您 web 站点的名称。预编译站点之后,对站点内页面的请求也应随即完成,而不会有任何编译滞后。

    部署预编译

    第二种预编译模式使您可以创建整个 web 站点的可执行版本,部署这种版本不需要任何源代码(包括 html 和其他静态文件)。因此,部署预编译可以防止别人随意访问由代码表示的知识产权信息。生成的程序集和 stub 文件集可以通过 xcopy、ftp、windows 资源管理器等部署到生产服务器上。为了预编译站点以进行部署,asp.net whidbey 提供了一个名为 aspnet_compiler.exe 的命令行实用程序。要在文件系统 web 站点上调用 asp.net 预编译器,需要打开一个命令窗口,浏览到 .net framework 的安装位置(/microsoft.net/framework/<版本>),然后输入以下命令:

    aspnet_compiler /v /<websitename> -p <source> <destination>


    其中 为 web 站点的名称(即在浏览器中输入的名称),为两个文件系统路径,分别指向要编译站点的位置以及编译后的版本应输出至的位置。以我们的 web 站点为例,输入的命令如下所示(请注意下面是一条命令):

    aspnet_compiler /v /compilation -p c:/websites/compilation c:/websites/compilation_compiled


    如果要查看 asp.net 预编译器的所有可用选项,只需输入以下命令:

    aspnet_compiler /?


    请注意,某些命令行选项要求 web 站点必须为有效的 microsoft® internet 信息服务 (iis) 应用程序才能正常工作。如果在 microsoft® windows 资源管理器中浏览至目标目录,您会看到预编译 web 站点后将生成一个包含 bin 目录的站点,bin 目录中包含一些程序集和描述性文件,以及大量与原始页面同名的 stub 文件,但不包含代码(包括 html 和可执行代码)。如果浏览此站点,输出与原始站点的输出相同。请注意,不能在已进行部署预编译的站点上使用在位预编译,原因很简单,因为它已经被预编译过了。

    intellisense 无处不在!

    对于 visual studio .net 2002 和 2003,最令我头痛的问题之一(相信很多开发人员也有同感)就是对 intellisense 和其他用于提高生产率的功能的支持不一致。希望在 html 视图中将控件从工具箱中拖到页面上吗?还做不到。事实上,在 html 视图中根本看不到工具箱的 web 窗体面板!要在 .aspx 页面上写入内嵌代码而不是使用模块化代码?可以做到,但必须放弃 intellisense、拖放功能以及其他更多功能。最后,正如我最近在 msdn asp.net developer center 上发表的文章中提到的,在 visual studio .net 2002 或 2003 中获得自定义控件的设计时支持需要跨越层层障碍,包括有点粗糙但奏效的 xsl 修改。

    令人高兴的是,asp.net whidbey 中实现了编译模型的统一,所有这些问题也都迎刃而解。在 visual studio .net whidbey 中,可以写入内嵌代码或使用新的模块化代码模型,还能获得控件拖放、intellisense 语句完成以及所有以前您希望使用却因编码方式局限而无法使用的那些可以提高生产率的功能。另外,对自定义服务器控件和 web 控件的设计时支持有了很大的改进,包括为源视图(html 视图在 visual studio .net whidbey 中的等效视图)中的自定义控件增加了 intellisense 语句完成。

    小结

    asp.net whidbey 中对编译模型的更改,以及 visual studio .net whidbey 中相应功能的改进无疑是一个巨大的飞跃,不仅为开发人员提供了所需的灵活性,还使他们可以充分利用 ide 提供的可以提高生产率的功能。大大简化的模块化代码模型将使该功能更有用、更简捷,而新增的对内嵌代码的完全支持显然会受到那些希望所有代码都位于一个 .aspx 文件中的开发人员的欢迎。相信 /code 目录会大大提高生产率,对于那些从事发展迅速的中小型项目的开发人员,以及那些因为编译过程过于复杂而无法完成工作的开发人员来说尤其如此。它还为访问业务逻辑组件、资源文件、wsdl 文件以及其他资源提供了一种更为直接、简单的方法:通过自动编译、嵌入或创建这些资源的代理并自动引用它们,只需很少的代码即可访问这些资源。

    预编译功能使开发人员可以轻松地提高其站点的初始性能,如果需要,还可以通过提供功能完备的 web 应用程序(不包含源代码或 html)为重要的知识产权信息添加保护措施。最后,集所有功能于一身的 visual studio .net whidbey 无疑会为开发人员带来非凡的体验,他们不仅能从内嵌代码模型和模块化代码模型中获得完全的 intellisense 支持,还能查看给定页面的所有视图,开发工作不会再因工具限制而局限于某一种样式。

    发表评论 共有条评论
    用户名: 密码:
    验证码: 匿名发表