ASP.NET 预编译命令(解决发布后第一次访问慢问题)

ASP.NET 编译工具 (Aspnet_compiler.exe) 官方说明

新建bat文件

  1. @echo off

  2.  

    CD /d C:\Windows\Microsoft.NET\Framework\v2.0.50727

  3.  

    aspnet_compiler -p E:\wwwroot\站点主目录 -v /

  4.  

    echo 命令执行成功!

  5.  

    pause

请注意,上面的v2.0.50727代表项目的.NET版本,可根据项目版本替换成以下版本

v2.0.50727

v3.0

v3.5

v4.0.30319

每次发布新版本后,执行下此bat文件即可完成预编译,并且会自动检测提示异常



DUDU:

为什么要用预编译?

博客园博客程序中.aspx和.ascx文件总共加起来有3000多个(博客模板中有大量的.ascx文件)。如果使用动态编译,每次只要更新bin文件夹中的任何一个dll文件,动态编译至少需要5分钟(访问量越高,所需的编译时间越长),而在动态编译期间网站访问速度极慢,几乎就是无法正常访问。这样,每次更新程序成为了一种痛苦,只能安排在深夜或一大早。

面对这样的情况,只能选择预编译。

预编译的原理是什么?

请阅读Artech写的深入剖析ASP.NET的编译原理之二:预编译(Precompilation)

如何进行预编译?

用aspnet_compiler命令,命令示例:

aspnet_compiler -v \ -p G:\SourceWebSite G:\TargetWebsite -fixednames

参数说明:

-v \  要编译的虚拟路径,这里表示根路径。

-p G:\SourceWebSite 要编译的源Web项目所在文件夹。

G:\TargetWebsite 编译目标文件夹。

-fixednames 每个.aspx与.ascx文件都编译生成单独的dll文件,并使用固定文件名。

编译情况分析

1. 源文件夹中的所有.aspx, .ascx及App_Code中的.cs文件都会被编译。

2. 编译中遇到任何一个错误,会立即停止编译,并清空目标文件夹中已生成的文件;解决了引起编译错误的问题后,只能从头重新进行编译。出现编译警告,只提示,不影响正常编译。

3. 编译完成后,aspnet_compiler会将.aspx, .ascx, .cs之外的所有文件原封不动地复制至目标文件。(如果编译只是为了更新网站程序,这个操作显得多余。aspnet_compiler没有提供取消这个操作的参数)

4. 3000多个.aspx,.ascx文件,使用-fixednames编译,耗时30分钟左右;不使用-fixednames编译,只要6分钟。-fixednames编译本来是为了更新方便(每次编译生成的文件名相同,更新生产环境中的dll时直接覆盖就行),没想到这么慢。不用-fixednames编译,每次更新时,要先删除原来的文件,再复制。在生产环境中,这个操作会短暂影响网站的正常访问。

5. 预编译不会生成任何.ascx文件,也就是编译目标文件夹中没有任何.ascx文件。如果存在通过System.IO.File.Exists判断.ascx文件是否存在的代码,将不能按正常逻辑执行。解决方法是将.ascx文件复制到目标文件夹。

为什么不用“可更新的预编译(Updatable Pre-compilation)”

Updatable Pre-compilation只编译App_Code中的文件以及.aspx,.ascx的code behind文件,我们的Web项目类型是Web Application,code behind已经编译了,App_Code中也没有代码,相当于已经处于这种编译状态,但还是需要至少5分钟的动态编译时间。

这种编译方式只是减少了编译.cs文件的工作量,但每个.aspx,.ascx文件还是要动态编译,不能避免动态编译的性能问题。

Updatable Pre-compilation适用于App_Code中有大量代码(更新其中的文件会引起该文件夹中的所有文件重新编译),又不想用Non-updatable Pre-compilation的情况。

结论

面对这么多的.aspx,.ascx文件,只能选择预编译。-fixednames编译实在太慢,只能放弃。更新时只能先删除,再更新。虽然有些不足,但总比动态编译好。

当然,真正的解决之道是干掉模板中的那些.ascx文件。ASP.NET MVC会是救星吗?

原文地址:https://www.cnblogs.com/waw/p/9615134.html

时间: 2024-10-29 19:10:33

ASP.NET 预编译命令(解决发布后第一次访问慢问题)的相关文章

理解 ASP.NET 预编译

一.预编译的优点 1. 由于页和代码文件在第一次被请求时无需编译,因此可以缩短对用户的响应时间.这对于更新频繁的大型网站尤为有用 2. 可以在用户看到网站之前识别编译时的 Bug 3. 可以创建站点的已编译版本,并将该版本部署到成品服务器,而无需使用源代码 二.就地预编译与针对部署的预编译 1. 就地预编译 就地预编译网站可以有效执行用户在请求网页时所发生的编译过程.因此,主要的性能改进在于在第一次请求页时无需对该页进行编译. 编译后的文件存放在%SystemRoot%\Microsoft.NE

关于ASP.NET预编译的问题

第一次接触到vs2010的预编译,因为网站源码在部署到服务器上之前要经过预编译过程,其中的aspx文件.cs文件.以及master文件.app_code文件均被编译,然后放到了bin目录下.这样不仅对网站安全有好处(不直接存放源代码),而且在用户访问网站时不用在经过漫长的预编译过程,使响应速度加快. 预编译步骤: 1.运行cmd,打开命令行后,连续输入"cd.."段字符将目录调至c:\>下 2.输入aspnet_compiler.exe文件的详细物理路径,一般是在"C:

预编译命令简单解释(转载)

我的blog是用开源的BlogEngine来架设的,有的时候为了满足自己的需求及要对源代码做一些修改.在我调试客户端代码的时候,不管是使用Firebug或者是Vs 2008来调试,看到的Javascript代码都是经过动态压缩过了的,这个系统有一个HttpHanddle是专门用来处理js文件请求的,在第一次请求的时候会对js代码进行压缩,去掉了注释换行符等不必要的字符,这样可以提高访问的速度,但是对调试非常的不利,相信我们谁都不愿意对着一堆压缩过了的JS代码做调试.于是我想到了C#的预编译指令,

预编译命令 #if DEBUG

在控制台程序根据预编译命令: namespace SXGYCarTransfrom.Handle { class Program { static void Main(string[] args) { #if DEBUG RunAsConsole(); #else RunAsServer(); #endif } /// <summary> /// DEBUG 时跑的为控制台程序 /// </summary> private static void RunAsConsole() {

.NET网站自动浏览器分享,解决IIS6应用池回收后第一次访问慢问题

.NET开发的网站,如果不是使用预编译发布,网站会在iis6应用池回收后第一次访问很慢,为了解决这个问题,今天写了一个自动浏览的工具,现在分享给大家,界面如下. 关键部分源码 //手动点击浏览 private void btnBrowsing_Click(object sender, EventArgs e) { if (btnBrowsing.Enabled == true && chkEnableAutomaticBrowsing.Checked == true) { btnBrows

asp.net 预编译和动态编译

在asp.net中,编译可以分为:动态编译Dynamical Compilation和预编译(Precompilation). 动态编译 深入剖析ASP.NET的编译原理之一:动态编译(Dynamical Compilation) 预编译 深入剖析ASP.NET的编译原理之二:预编译(Precompilation) 比如vs2013发布站点的时候,可以选择预编译,生成单独文件. 发布后,你可以看到bin目录下的文件

Asp.Net Core IIS 7.5 发布后PUT、DELETE请求错误405.0 - Method Not Allowed 因为使用了无效方法(HTTP 谓词)

Asp.Net Core IIS发布后PUT.DELETE请求错误405.0 - Method Not Allowed 因为使用了无效方法(HTTP 谓词) 一.在使用Asp.net WebAPI 或Asp.Net Core WebAPI 时 ,如果使用了Delete请求谓词,本地生产环境正常,线上发布环境报错. 服务器返回405,请求谓词无效. 二.问题分析诊断 首先检查跨域配置是没有问题的,查询数据和新增数据的请求也是没有问题的,只出现在修改和删除数据.通过了解ABP Web API请求头设

IIS进程回收后第一次访问慢的问题

IIS 有一种机制,默认会在IIS空闲一定时间段后,将应用程序池进行回收,这个时间段在IIS6中默认是20分钟,在IIS7中默认是1740分钟.两个配置都不合理,都会导致当应用程序池被回收后,第一次访问网站的时候速度很慢.如果一直不回收应用程序池,会导致占用内存过大. 做SharePoint的人都知道,站点每天访问第一次登录的人都很慢.也是这个IIS回收机制的问题.我们的希望是每天凌晨进行应用程序池回收,并同时进行第一次访问,这样每天工作时间访问的时候速度都是很快的.具体做法是:1. 在IIS中

解决wcf发布后无法访问

一般是在安装 Windows Communication Foundation (WCF) 之后安装了 IIS造成,运行以上命令将在 IIS 中注册所需的脚本映射. 这时将确保在MIME中将 .svc 文件类型映射到 aspnet_isapi.dll. 运行cmd,输入: C:\Windows\Microsoft.NET\Framework\V4.0.30319\aspnet_regiis -i 注册成功后,重启一下iis, 理论上应可以解决导致404.17 not found 的大部分问题了