Temporary ASP.Net Files探究

了解.net平台的兄弟都知道，.net也是采用动态编译的 也就是说我们常说的build生成的dll只是中间代码 而在web第一次请求的时候才是真正意义上的编译生成二进制代码 这也就是为什么刚编译完第一次打开web页面的时候会比较慢的原因 好了，闲话少扯 今天一个兄弟问我，为什么他开发环境打开编译后的页面越来越慢 下面是我的解决方案： 1.关掉inetinfo.exe的进程 2.关掉aspnet_wp.exe 3.关掉打开的visual studio 4.清掉%SystemRoot%\Microsoft.NET\Framework\versionNumber\Temporary ASP.NET Files文件夹下的所有文件。 %SystemRoot%指的是你的系统windows文件夹的路径，一般默认的是C:\WINDOWS\ 整个清除过程可能会比较慢，具体时间和目录下文件夹大小有关。 清除完之后，第一次打开还会比较慢，但是以后编译后的打开会快一些。 下面是详细的解释 当我们第一次请求的时候，也就是正式编译的时候，dotnet会写一些临时文件在这个文件夹下。 这个本人验证过，在第一次请求的时候，去关注文件夹的变化。 对于部署在server已经上线的Web Application是不会存在这样的问题的。 而在我们的开发环境下，由于经常要build，经常第一次请求，所以时间久了，这个文件夹就会变得很大。 像我现在在做的项目，源文件和目标文件的大小有4G，那么，写到这个文件夹里的文件就有上百兆。 我们可以去关注下，在选择“附近到进程”操作之后加载的程序集，就是在这个路径下。 不知道有的兄弟，会不会想，要经常手动去清这些文件，岂不是很麻烦？ 哈哈，想省事的兄弟，可以写个批处理程序来做这个操作。 这里，我想介绍另一种方法来提升速度。 我们都知道，在我们可以控制的存储单元中，内存的访问速度是最快的。 如果，我们可以把这些临时文件放到内存中，就会成倍地提高速度。 1.安装RamDisk 2.安装好后，设置Debug 输出的Temp 目录为内存盘的path, 不再使用原来预置的 Temporary ASP.NET Files，只需要通过修改 Web.Config 文件中的 一般情况是这样的 修改为 保留原来属性，新加一个 tempDirectory 指定内存盘的path 实践检验，可以花费时间的差距可以到一个数量级。 扩展阅读：http://msdn.microsoft.com/en-us/library/ms366723.aspx

作为一名 ASP.NET 开发人员，您可能非常清楚 ASP.NET 如何处理 .aspx 资源中的代码，如何对标记进行分析并将其动态转换成 Visual Basic ® 或 C# 类，等等。但是接下来呢？ASP.NET 生成的文件保存在哪里？如何利用它们满足页面请求？从上个月起，我开始关注这一过程。 在本月的内容中，我将对服务器上所发生的操作进行分析，以便您能够避免某些常见的问题隐患。 我将讨论 ASP.NET 临时文件的存储以及动态生成的用于为页面响应提供服务的类的源代码。此外，我还将构建一个可以与任何 ASP.NET 2.0 或 ASP.NET AJAX（原代号为“Atlas”）应用程序一同使用的资源管理器工具，以查看和调试您的页面执行的实际代码。但在此之前，您需要了解几个事项。（和上月专栏一样，本部分内容主要以那些没有文档记录的 ASP.NET 工作原理细节为基础来展开。这些实施细节在未来的 Microsoft ® .NET Framework 版本中可能会发生变化。）

Temporary ASP.NET Files 文件夹中保存的是什么内容？

ASP.NET 页面请求的处理过程需要使用一些临时文件。当您在 Web 服务器上安装 ASP.NET 2.0 时，所创建的文件夹层次结构如下：

%WINDOWS%\Microsoft.NET\Framework\v2.0.50727

这里的版本号指的是 ASP.NET 2.0 的零售版。ASP.NET 的每个发布版本（包括每个过渡性的内部版本）都有一个唯一的版本号，并且会创建不同的文件夹树，以便支持不同版本的并行执行。因此，您务必要指定您的应用程序所适用的 ASP.NET 版本，这一点极为重要。在 ASP.NET 1. x 和 ASP.NET 2.0 下运行的应用程序基于物理形式上独立的文件夹。在 Microsoft.NET\Framework 文件夹下，您会找到与已安装的 ASP.NET 版本数相同数量的 vX. X. XXXX 子文件夹（请参见 图 1）。

图 1  ASP.NET 1.0、1.1、2.0 和 3.0 运行库文件 (单击该图像获得较大视图)

在已安装版本的根文件夹下，您会看到许多子目录。CONFIG 文件夹包含计算机配置文件，其中包括 machine.config 和用于所有站点的基本 web.config 文件。名为 ASP.NETWebAdminFiles 的文件夹包含构成网站管理工具的源文件，您可从 Visual Studio ® 2005 内部运行该工具。最后，Temporary ASP.NET Files 文件夹包含为页面和资源提供服务而创建的所有临时文件和程序集。要找到为您的 Web 页面动态创建的文件，您需要查看此文件夹子树。请注意，Temporary ASP.NET Files 目录是存放动态创建的文件的默认位置，但可以使用 web.config 文件中的 <compilation> 部分按应用程序对其进行配置：

<compilation tempDirectory="d:\MyTempFiles" />

当应用程序第一次在计算机上执行时，在临时文件目录下就会创建一个新的子文件夹。编译子文件夹的名称与应用程序的 IIS 虚拟目录的名称相同。如果您只是使用 Visual Studio 2005 内嵌的 Web 服务器测试应用程序，那么子文件夹会采用该 Web 应用程序的根文件夹的名称。如果您从 Web 服务器的根文件夹调用页面，您将在根子文件夹下找到它们的临时文件（请参见 图 2）。

图 2  Web 测试服务器上的 WebApp (单击该图像获得较大视图)

在应用程序的编译子文件夹下，有一组使用散列名称的目录。此处显示了通常可以找到临时文件的路径。（最后两个目录包含的是假名称，但实际显示的就是这样的名称。）

\v2.0.50727\Temporary ASP.NET Files\MyWebApp\3678b103\e60405c7

您可以使用以下语句，以编程的方式检索指定应用程序的临时文件所在的子文件夹的路径：

Dim tempFilesFolder As String = HttpRuntime.CodegenDir

ASP.NET 会定期在应用程序发生改变、需要重新编译时清理编译文件夹并删除陈旧的资源，但 Temporary ASP.NET Files 目录下的子树的大小可能会显著地增加，在测试计算机上更是如此。 作为管理员，您应密切关注 Temporary ASP.NET Files 下的目录，并确保所有目录都是与当前活动的应用程序有关的。如果您无意间删除了一个处于活动状态的应用程序的子树，不必惊慌。您将丢失所有预编译的页面和资源并会将应用程序重置到其最初的编译状态；但下一个请求将触发对每个页面或一批页面（具体取决于配置）执行新的编译过程，因此最终不会丢失任何信息或页面，只不过用户在处理下一个请求时将感觉到首次命中延迟。现在，我们来看某一应用程序的编译文件夹的内容。

保留文件

对于应用程序中的每个页面，页面编译进程会生成一个下述名称的文件：

[page].aspx.[folder-hash].compiled

[page] 占位符代表 .aspx 资源的名称。[folder-hash] 占位符是一个散列值，它使文件名保持唯一，避免与原本属于其他文件夹的同名文件混淆。这种文件称为保留文件，因为它们包含有重要的信息，这些信息可帮助 ASP.NET 运行库快速检索程序集以及检索将用于为页面请求提供服务的 HTTP 处理程序的类型名称。此外，保留文件还包含一个文件散列值，用于检测自从上次访问后文件的内容是否发生了改变。

构成某一应用程序的所有 .aspx 页面在同一个临时文件夹中进行编译，即使它们名称相同且位于不同的文件夹中也是如此处理。这一点如何实现？假设您的应用程序包含两个名为 test.aspx 的页面，位于不同的文件夹 － Folder1 和 Folder2 中。两个页面将在同一临时文件夹中进行编译，但可以通过它们的散列值对其进行区分，由于散列值是根据路径信息而不只是文件名计算出来的，因此它们的散列值是不同的。 因而最终，两个 test.aspx 页面的保留文件名只在文件夹散列值部分有所不同：

Test.aspx.cdcab7d2.compiled
Test.aspx.9d86a5d7.compiled

散列值的内部存储缓存使 ASP.NET 运行库可以识别任何指定页面 URL 的散列值并快速找到相应的保留文件。如果没有找到保留文件，ASP.NET 会动态编译页面。当您部署没有预编译的应用程序时就会发生这种情况。另一方面，当您对一个站点进行预编译时，每个组成页面的保留文件被创建并放置在 Bin 文件夹中。

保留文件为纯 XML 文件。 图 3 显示了一个示例保留文件的内容。

转载于:https://www.cnblogs.com/bobzhao/articles/1937169.html