.NET Framework 3.5 不原生支持PreApplicationStartMethod特性

.NET Framework 3.5 不原生支持PreApplicationStartMethod特性 。这个特性是在 .NET Framework 4.0 中引入的，用于在应用程序启动早期执行初始化逻辑。

在.NET 3.5 中，如果你需要实现类似的 "应用启动时自动注册模块" 功能，需要通过手动配置web.config 来注册 HTTP 模块，无法像.NET 4.0 + 那样通过特性自动触发。

.NET 3.5 的替代方案：手动注册 HTTP 模块

保留模块和初始化逻辑（代码无需大幅修改）：vb
复制代码
```
' 模块类（与之前相同）
Public Class UploadToolModule
    Implements IHttpModule
    ' ...（实现Init、Dispose等方法）
End Class
```
在web.config中手动注册模块：
- type属性格式：[完整类名], [程序集名称]（即 DLL 文件名，不含.dll后缀）
- 同时配置httpModules和modules可兼容不同 IIS 运行模式

xml

复制代码

<configuration>
  <system.web>
    <!-- 适用于IIS经典模式 -->
    <httpModules>
      <add name="UploadToolModule" type="XiaoYaoWebCore.UploadToolModule, XiaoYaoWebCore" />
    </httpModules>
  </system.web>
  <system.webServer>
    <!-- 适用于IIS集成模式 -->
    <modules>
      <add name="UploadToolModule" type="XiaoYaoWebCore.UploadToolModule, XiaoYaoWebCore" />
    </modules>
  </system.webServer>
</configuration>

关键区别总结

框架版本	是否支持`PreApplicationStartMethod`	注册模块方式
.NET 3.5 及以下	不支持	必须手动在`web.config`中配置
.NET 4.0 及以上	支持	可通过特性自动注册或手动配置

因此，在.NET 3.5 中，无法通过PreApplicationStartMethod实现 "零配置" 自动加载，必须手动在web.config中注册模块才能使其生效。

如何在项目中设置才能让.NET 3.5支持PreApplicationStartMethod？

除了PreApplicationStartMethod，还有哪些方法可以在应用启动时自动执行代码？

在IIS集成模式下，如何确保手动注册的模块能够正确工作？

UploadToolInitializer类的Initialize方法会被自动调用，核心原因是它被PreApplicationStartMethod特性标记 ------ 这是.NET Framework 提供的一种应用启动时自动执行代码 的机制，专门用于在ASP.NET应用初始化阶段运行指定逻辑（如注册模块、配置初始化等）。

具体原理：

PreApplicationStartMethod特性的作用

你在代码中定义了程序集级别的特性：vb
复制代码
```
<Assembly: PreApplicationStartMethod(GetType(UploadToolInitializer), "Initialize")>
```
这个特性告诉ASP.NET：在应用程序启动（创建应用域）的早期阶段，自动调用UploadToolInitializer类的Initialize静态方法。
调用时机

该方法的执行时机非常早：
- 早于Global.asax中的Application_Start事件
- 早于任何 HTTP 模块的初始化
- 早于第一个请求到达之前
此时ASP.NET正在初始化应用环境，通过扫描所有已加载的程序集（包括你放入bin目录的 DLL），发现并执行标记了PreApplicationStartMethod的方法。
为何能自动发现

当你将编译好的 DLL 放入ASP.NET项目的bin目录后：
- 应用启动时，ASP.NET会自动加载bin目录中的所有程序集
- 扫描程序集中的全局特性（包括PreApplicationStartMethod）
- 按特性指定的类型和方法名，通过反射调用Initialize方法
整个过程无需手动配置web.config，完全依赖.NET 的特性扫描机制。

总结

UploadToolInitializer被调用的本质是：
PreApplicationStartMethod特性为 DLL 提供了一个 "钩子"，让ASP.NET在应用启动时自动执行指定方法 ，从而实现模块注册等初始化逻辑。这也是为什么只需将 DLL 放入bin目录，无需额外配置就能生效的核心原因。

在IHttpModule的OnBeginRequest事件中，确实会对所有请求进行拦截（包括静态资源如.htm、.jpg 等），但这并不意味着会 "阻塞" 请求处理，而是提供了一个介入点。以下是具体解释：

1. 是否关于 "每个请求是否会在这里停一下"

是的，所有请求都会经过这里 ：BeginRequest是ASP.NET管道中最早的事件之一，所有 HTTP 请求（无论动态请求动态页面、静态资源还是 API）都会触发此事件。
但不会 "停住" 整个处理流程 ：模块只是在请求处理的早期 "路过" 这个事件，执行你编写的代码（如判断路径、处理逻辑等）。如果你的代码没有调用response.End()或response.Close()，ASP.NET会自动继续执行后续的管道事件（如授权、路由、页面处理等），最终交给原本的处理程序（如静态文件处理器、ASPX 页面引擎等）。

2. 如果不写入数据，会自动转向原来的处理程序吗？

是的：IHttpModule的设计是 "拦截 - 处理 - 传递" 模式。
- 如果你在事件中没有修改响应 （如不调用response.Write()），也没有终止响应 （如不调用response.End()），则请求会继续沿着管道流动，最终由原本的处理程序处理（例如：.htm 文件由静态文件模块处理，.aspx 由页面处理器处理）。
- 只有当你主动调用response.End()时，才会终止后续处理，直接返回响应。

3. 静态页面（.htm、.jpg 等）会被拦截吗？

取决于 IIS 的运行模式：
- 集成模式（推荐） ：静态资源请求会经过ASP.NET管道，因此BeginRequest事件会拦截所有请求（包括.htm、.jpg、.css 等）。
- 经典模式 ：静态资源由 IIS 内核直接处理，不会经过经过ASP.NET管道，因此BeginRequest不会会拦截静态资源，只处理动态请求（如.aspx、.ashx）。

验证方式 ：可以在OnBeginRequest中添加日志输出，测试访问静态文件时是否会触发：

复制代码

Private Sub OnBeginRequest(sender As Object, e As EventArgs)
    Dim app As HttpApplication = DirectCast(sender, HttpApplication)
    ' 记录所有请求的路径
    Debug.WriteLine("请求路径：" & app.Request.Path)
End Sub

总结

IHttpModule的BeginRequest会拦截所有经过ASP.NET管道的请求（集成模式下包括静态资源）。
不写入数据且不终止响应时，请求会自动交给原本的处理程序，不影响正常流程。

若需避免处理静态资源，可在事件中添加过滤逻辑：

复制代码

' 只处理动态请求，跳过静态资源
If app.Request.Path Like "*.aspx" Or app.Request.Path Like "*.ashx" Then
    ' 你的处理逻辑
End If

这种设计让模块既能灵活介入请求处理，又能保持原有流程的完整性，是ASP.NET中扩展请求处理的常用方式。