我正在使用 mvc3，虽然我经常看到这个问题，但我还没有找到关于使用哪种技术的明确答案。大多数解决方案似乎相互矛盾，使用旧库和新库的混搭。似乎有很多关于异步的讨论，但随后出现了很多关于为什么它不“安全”的答案。
需要的是。
MVC3 网站 - 用户单击按钮以创建报告。
报告很大，将创建并存储在 Web 服务器磁盘上（可能需要长达 10 分钟）。
用户不需要知道报告何时完成创建。
该网页仅返回正在创建报告的事实，并允许您继续，而无需再次与该过程进行交互。
为了争论，服务器硬件相当不错，但可能有超过 100 个并发用户，他们都在完全相同的时间创建自己的单独的大报告。我希望它可能产生的唯一问题是服务器硬件足够强大，而不是配置或软件问题。
我一直在寻找“任务并行库”作为执行此操作的方法。但我再次收到许多关于如何做到这一点的不同报告。
有些人建议使用 WCF 服务，但关于为什么/为什么不这样做的许多相互矛盾的报告。即现在过时/更好的替代品等
一般来说，我想要的是在另一个不会弄乱 iis 的线程中创建文件（根据使用的方法，从池中耗尽线程等）
这是一组非常开放的问题。这不是一件坏事，但没有多少“正确”的直接答案。但是有一些事情需要注意。一些选择取决于您的可靠性要求等。
例如，您想要一个不会“弄乱 iis”的方法，指的是使正在服务请求的线程池处于饥饿状态。为此，您需要在线程池之外的线程上进行工作。您可以以任何您认为合适的方式执行此操作，具体取决于您的要求和测量的性能特征。您的两个选项是：
还有第三个选项可以使用内置到您选择的框架中的异步支持。对于 MVC，您有异步控制器。我不会将此列为您的选项，因为您说过您不想在发送响应之前等待报告完成。异步控制器/页面在这里不会给您带来任何好处，实际上会受到伤害。
可靠性方面你也要考虑对方：是的，你不想弄乱iis，但你是否也关心iis弄乱了你？您的 Web 流程可以被回收，或者如果它因任何其他原因出现故障，您的报告生成也将终止。如果这对您很重要，那么您必须有一个恢复机制或托管进程，以便您可以单独控制服务的可靠性。
托管进程外的另一个好处是您可以将该进程物理部署在与前端应用程序不同的服务器上。然后，您可以优化以使用该应用程序中的线程池，而无需与前端有任何关系。如果你一次有很多事情发生，它也会减少上下文切换。此外，如果需要，您可以单独扩展报告生成过程。最后，如果这是您要走的路，您可以单独处理权限和其他自动化 excel 等问题。
进程外的缺点是增加了复杂性。您需要在两者之间进行一些通信，可能是 WCF 单向调用，可能是消息总线，无论您的要求如何。您需要权衡此成本与您的需求以及您期望从可靠性/可扩展性/等方面获得的价值。
现在，对于您选择的执行异步工作的工具，这在很大程度上取决于您。在我看来，TPL 是对异步工作的一个很好的抽象，并且用于运行任务的默认任务调度程序对线程使用非常智能，因此您基本上不必考虑太多。此外，.NET 4.5 提供了内置的编译器支持，使得使用 TPL 比现在更简单，并且看起来更像同步风格（搜索 async/await 或者从这里开始作为示例。）
底线是，我不会对一般使用哪种技术堆栈过于紧张或麻痹。列出你的非功能性需求——性能、可扩展性、可靠性等——找出适合你的需求的组合，然后选择一个。如果您担心做出错误的选择，请尝试以一种允许您有效应对该领域变化的方式来构建解决方案。如果需要，您可以随时测量和更改。