ThreadPool.QueueUserWorkItem 所需的用户答案

【问题标题】：Required user for ThreadPool.QueueUserWorkItemThreadPool.QueueUserWorkItem 所需的用户
【发布时间】：2017-04-09 05:12:21
【问题描述】：

也许这个问题不在这里......

我正在使用ThreadPool.QueueUserWorkItem 写入文件夹/文件，我的问题是当它尝试写入时我得到了UnauthorizedAccessException。

所以我更改了目录以允许每个人都可以写入并且它可以工作。

但我不想让每个人都写作。 ThreadPool.QueueUserWorkItem 使用的用户/组似乎与主线程不同。

应该是什么用户？

【问题讨论】：

【解决方案1】：

因为它是一个 IIS 应用程序，所以您必须授予权限的用户是 the user the application pool runs under。

您的主线程可能会冒充请求所针对的用户。后台工作项不再与用户关联。

PS：IIS中使用的ThreadPool.QueueBackgroundWorkItem是a very bad idea，需要在IIS中使用更合适的后台工作工具。

【讨论】：

有趣的答案！但这对我提出了很多问题。 1. 问题是否仅发生在ThreadPool.QueueUserWorkItem 上，正是因为它在 ASP.NET 中并不真正推荐/支持？即使 TPL（即 Task.StartNew）2. 可能构建在 ThreadPool 之上，模拟也会成为问题吗？ 3. 如果 ASP.NET 中的所有异步内容都是一个坏主意，那么 ASP.NET 拥有异步设施（例如异步 HTTP 处理程序）会很奇怪，人们会遇到奇怪的问题，例如使用 TPL 时，OP 一直都在...？
通常不会在 IIS 上启动后台线程，您已经在线程池线程上，如果您使用异步功能（如 async/await），上下文会随用户流动。有关更多信息，请参阅本文msdn.microsoft.com/en-us/library/aa954062.aspx
适合 IIS 的工具应该是什么？
@stakx 我被切断了。在我的手机上打字。更好的措辞是“异步等待上下文流过线程间的等待，包括用户的安全身份”
这里有一些关于异步上下文流的更有用的阅读，也请阅读开头提到的相关文章。 vegetarianprogrammer.blogspot.com/2012/12/…