网站内容发布流程图(Web应用程序在VS中生成解决方案之后的目录下的文件 )

　　网站内容发布流程图(Web应用程序在VS中生成解决方案之后的目录下的文件

)

　　创建一个简单的 asp.Net web 应用程序，如下所示

　　在VS中生成解决方案后，在项目目录下可以看到如下文件：

　　当我们通过VS发布网站时，可以看到最终生成的文件如下图所示：

　　发布后我们可以发现项目文件夹中丢失了很多文件。其实这就是VS把aspx页面，一般的处理程序，以及Global文件的后台文件编译成一个dll文件。dll 文件存储在 bin 文件夹中。里面：

　　反编译这个程序集后，可以看到我们写的后台代码编译成了这个dll文件

　　这是通用处理程序的 ProcessRequest 方法中的代码。可以看到是我们写的源码：

　　至此，项目文件夹中的几个文件中只剩下几个简单的声明，所有的后台代码都没有了：

　　全局文件：

　　一般处理程序：

　　aspx页面：

　　然后我们使用下面的代码来获取页面，一般的处理程序，以及全局编译和运行时的位置：

　　System.Reflection.Assembly.GetExecutingAssembly().Location

　　经过对比可以发现，Global文件、通用处理程序、aspx后台代码所在的程序集文件是一样的，而aspx前台页面的代码运行在另一个程序集中。以下是操作的结果：

　　Global和aspx页面的前后台运行文件：

　　一般处理程序的后台代码：

　　我们可以看到，IIS在运行网站时，网站的编译后的dll文件实际上是放在对应Framework版本的临时文件夹中

　　即C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files下，网站中自己编写的后台代码和类库以及引用的类库被编译到该临时文件夹中当前项目所在文件夹中的程序集文件。

　　网站 发布后文件分布图：

　　这时，对比发布的网站根目录下bin文件夹中的dll文件和运行通用加工程序的程序集，可以发现两者是同一个文件：

　　这时，如果删除网站根目录下bin文件夹中的dll，再浏览页面，会发现网站无法正常运行：

　　从上面的结果可以看出，虽然网站中已经有后台代码的dll文件，但网站实际运行的是system文件夹中的dll文件。这个应该是直接从网站@网站复制过去的，它们的MD5值完全一样。

　　这里可以推测，对于asp.Net应用，IIS只会编译aspx页面、通用处理程序、Global等文件，而不会编译其他类文件。所有的类文件对 IIS 都没用。IIS 只能使用编译后的 dll 文件。

　　网站运行时，系统文件夹中的dll文件无法删除，说明被IIS Worker Process占用。这说明网站在运行时实际使用了这个dll文件

　　那么这个 IIS Worker Process 进程是什么？当我们结束当前网站对应的w3wp.exe进程后，系统文件夹中的dll就被成功删除了。这说明这个dll的调用者是w3wp.exe 这个进度也说明w3wp.exe是网站的工作进程。

　　当我们删除system文件夹中的dll文件时，当我们再次访问网站时，又会在system文件夹中重新生成dll文件，第一次访问时报错：

　　如果你再次访问是正常的

　　总结：

　　因此可以得出结论，当asp.Net应用程序在IIS中运行时，前台页面的代码会立即更新和编译。当我们修改前台代码时，不需要重新编译项目或重新发布网站。访问网站时，IIS（或.Net框架？）检测到页面被修改，会帮助我们重新编译页面，当后台代码和其他类文件被修改时，我们需要手动执行源码代码重新编译。

　　以上内容针对Asp.Net应用

<p>对于Asp.Net网站，发布网站时，不会将页面、通用处理程序等一些代码编译成dll文件，只将源文件和一些引用的库复制到