Temporary ASP.Net Files探究

了解.net平台的兄弟都知道，.net也是采用动态编译的
也就是说我们常说的build生成的dll只是中间代码
而在web第一次请求的时候才是真正意义上的编译生成二进制代码
这也就是为什么刚编译完第一次打开web页面的时候会比较慢的原因

好了，闲话少扯
今天一个兄弟问我，为什么他开发环境打开编译后的页面越来越慢
下面是我的解决方案：
1.关掉inetinfo.exe的进程
2.关掉aspnet_wp.exe
3.关掉打开的visual studio
4.清掉%SystemRoot%Microsoft.NETFrameworkversionNumberTemporary 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 文件中的
  <compilcation debug=”true”> 一般情况是这样的
修改为   <compilcation debug=”true” tempDirectory=”R:”>
保留原来属性，新加一个 tempDirectory 指定内存盘的path
实践检验，可以花费时间的差距可以到一个数量级。
扩展阅读：http://msdn.microsoft.com/en-us/library/ms366723.aspx