【发布时间】:2011-09-15 05:21:21
【问题描述】:
我已经搜索了几个小时,但到目前为止没有运气 - 所以我想我会发布。
我有一个用 vb.net 编写的 WPF 应用程序,在 DotNet 4.0 上运行,它启动工作线程以执行特定功能,例如散列文件和其他处理器/时间密集型例程。
启动的某些线程需要模拟不同的用户才能访问登录用户通常无法直接访问的网络资源(允许它们通过应用程序对网络资源进行受控访问,但不能通过例如通过Windows资源管理器)。为此,工作线程模拟一个预先确定的用户帐户,该帐户具有访问权限,然后允许应用程序访问网络资源。
虽然在模拟用户帐户下运行的这个工作线程正在工作 - 它偶尔需要更新位于用户目录中的本地 sql 3.5 紧凑型数据库。该数据库只能由登录用户访问 - 而不是模拟用户。
为了允许此更新,我可以从模拟的工作线程访问 UI Dispatcher 对象(它在创建线程时传递),在该对象中我调用一个子例程来更新 SQL 紧凑型数据库。
这是一个有趣的问题,我无法解释,但请继续阅读,因为有人可能会解释这一点。
当应用程序从工作线程调用 UI Dispatcher 时,它会退回到登录的用户凭据以更新 UI 线程中的 sql 数据库 - 然后当 UIthread.dispatcher.invoke 调用返回到工作线程时 -它将回到模拟的工作线程帐户。
今天 - 我没有理由 - 当我调用 UI 调度程序线程来更新 SQL Compact 数据库时,线程上下文保留在模拟用户处 - 而不是 UI 线程上的登录用户。就像现在在所有线程(包括 UI 线程)上强加模拟用户一样。
我想了解的是正确的结果是什么 - UIThread.Dispatcher.Invoke 是否应该执行在 UI 线程的用户上下文(非模拟)下调用的任何代码,或者模拟的用户上下文是否生效UI线程上的invoke回调,因为它是从工作线程启动的?
我很困惑,因为昨天 - 当我在 UIThread.Dispatcher.Invoked 例程中有一个断点时,我可以看到线程正在登录的用户帐户下执行,并且对 SQL 紧凑型数据库的更新有效。然而,今天,在模拟帐户下执行相同的代码,我在尝试更新数据库时遇到拒绝访问异常。
我在启动工作线程之前检查了 UI 线程的 ManagedThreadId,并且能够确认执行 UIThread.Dispatcher.Invoke 时的 ManagedThreadId 返回到 UI 线程的 ManagedThreadId - 然后当调用结束并执行返回时对于工作线程,ManagedThreadId 返回到正确的工作线程 ManagedThreadId。这次没有改变的是该线程的用户。除非我明确结束线程的模拟,否则它现在似乎一直保留在模拟用户身上。
有人可以对此有所了解 - 并建议我是否将这一切都错了,应该尝试以另一种方式做到这一点。我真正想了解的是为什么它一直在工作 - 为什么现在它没有 - 而且没有 - 从昨天到今天,这段代码没有任何代码更改。
抱歉,帖子太长了
干杯
杆。
【问题讨论】:
标签: vb.net multithreading impersonation dispatcher