c# - Simple Injector 是否有任何技术原因无法支持 .NET 4.0 上的 Web API？

Question

这真的是对 this question 的跟进.一位 Simple Injector 开发人员指出了一个关于 Simple Injector 的有用花絮，我认为最好让它更易于访问。

那么，使用 Web API 1 和 .NET 4.0 支持 Simple Injector 是否存在任何技术障碍？源代码很容易下载和编译回来。它似乎工作得很好。

Answer 1

我们故意选择不支持 Web API 的 .NET 4.0，因为 WebApiRequestLifestyle 使用了 CallContext.LogicalGetData在 .NET 4.0 下表现不同。这种行为非常不同，以至于在后台线程和并行运行的 Tasks 中使用嵌套的 ExecutionContextScope 实例时可能会导致错误。

在这方面发生的变化是，在 .NET 4.5 中，逻辑调用上下文显示为 copy-on-write behavior ，这意味着当从并行操作中更改逻辑调用上下文时，它不会影响生成此并行操作的原始操作。在 .NET 4.0 中，并行操作中对逻辑调用上下文的任何更改都可以从主操作中观察到。

我们决定依赖 .NET 4.5 的这种写时复制行为，因为它允许从主操作中产生多个并行操作，这些操作都可以启动自己的 ExecutionContextScope (这是 Web API 集成包在后台使用的)隔离运行。这允许它们拥有自己的子作用域，并且当作用域被释放时，它们会在主要操作的作用域中再次运行。在后台线程中开始一个新的范围通常是您想要做的，因为您的组件将被并行访问，而它们可能根本不是线程安全的。启动新范围可确保当从容器解析新对象图时，如果新实例注册为 Per Web API Request 或 Per Execution Scope，则会创建新实例。

如果没有这种写入复制行为，并行操作会相互干扰并会看到其他并行操作的范围，这会导致这些范围嵌套，而实际上它们不会嵌套，而是会重叠。这将导致各种问题，例如导致回退到另一个并行操作的范围(而不是回退到主要操作的范围)。这当然是不正确的行为。

只要您只在异步流程中启动新的ExecutionContextScope(或者根本不启动新的范围)而不是在并行操作中启动新的范围，问题就不存在并且您的代码将在 .NET 4.0 和 .NET 4.5 下运行相同。

但由于这种行为根本不同，可能会导致各种问题，或者当它看起来有效时，可能会在您切换到 .NET 4.5 时再次中断，我们决定最好不要尝试这样做完全支持.NET 4.0。这可以防止开发人员落入这个陷阱，并且使我们自己的工作变得更加容易，因为我们不必记录这个根本差异，它也为我们节省了大量的支持时间，因为无论文档有多好，无论如何，开发人员将尝试在 .NET 4.0 下使用它，这可能会在 Stackoverflow 和 Simple Injector 论坛上引发许多新问题，我们必须回答这些问题。