[已编辑] This appears to be a bug在框架的实现中 Application.DoEvents ，我已报告 here .在 UI 线程上恢复错误的同步上下文可能会严重影响像我这样的组件开发人员。赏金的目的是让更多人关注这个问题，并奖励@MattSmith，他的回答帮助追踪了这个问题。

我负责通过 COM 互操作将基于 .NET WinForms UserControl 的组件作为 ActiveX 公开给遗留非托管应用。运行时要求是 .NET 4.0 + Microsoft.Bcl.Async。

组件在应用的主 STA UI 线程上被实例化和使用。它的实现利用了 async/await，因此它期望在当前线程上安装了一个序列化同步上下文的实例(即，WindowsFormsSynchronizationContext)。

通常，WindowsFormsSynchronizationContext 由 Application.Run 设置，这是托管应用程序的消息循环运行的地方。当然，非托管主机应用不是这种情况，我无法控制这一点。当然，宿主应用程序仍然有自己的经典 Windows 消息循环，因此序列化 await 延续回调应该不是问题。

但是，到目前为止，我提出的解决方案都不是完美的，甚至无法正常工作。这是一个人工示例，其中 Test 方法由主机应用程序调用:

Task testTask;

public void Test()
{
    this.testTask = TestAsync();
}

async Task TestAsync()
{
    Debug.Print("thread before await: {0}", Thread.CurrentThread.ManagedThreadId);

    var ctx1 = SynchronizationContext.Current;
    Debug.Print("ctx1: {0}", ctx1 != null? ctx1.GetType().Name: null);

    if (!(ctx1 is WindowsFormsSynchronizationContext))
        SynchronizationContext.SetSynchronizationContext(new WindowsFormsSynchronizationContext());

    var ctx2 = SynchronizationContext.Current;
    Debug.Print("ctx2: {0}", ctx2.GetType().Name);

    await TaskEx.Delay(1000);

    Debug.WriteLine("thread after await: {0}", Thread.CurrentThread.ManagedThreadId);

    var ctx3 = SynchronizationContext.Current;
    Debug.Print("ctx3: {0}", ctx3 != null? ctx3.GetType().Name: null);

    Debug.Print("ctx3 == ctx1: {0}, ctx3 == ctx2: {1}", ctx3 == ctx1, ctx3 == ctx2);
}

调试输出:

thread before await: 1
ctx1: SynchronizationContext
ctx2: WindowsFormsSynchronizationContext
thread after await: 1
ctx3: SynchronizationContext
ctx3 == ctx1: True, ctx3 == ctx2: False

虽然它在同一个线程上继续，但我在 await 之前在当前线程上安装的 WindowsFormsSynchronizationContext 上下文被重置为默认 SynchronizationContext 在它之后，出于某种原因。

为什么会被重置？ 我已经验证我的组件是该应用程序使用的唯一 .NET 组件。应用程序本身会正确调用 CoInitialize/OleInitialize。

我还尝试过在静态单例对象的构造函数中设置WindowsFormsSynchronizationContext，这样当我的托管程序集加载时它就会安装在线程上。这没有帮助:当稍后在同一线程上调用 Test 时，上下文已经重置为默认值。

我正在考虑使用 custom awaiter通过我的控件的 control.BeginInvoke 安排 await 回调，所以上面看起来像 await TaskEx.Delay().WithContext(control) .这应该适用于我自己的 awaits，只要主机应用程序不断发送消息，但不适用于我的程序集可能引用的任何第 3 方程序集中的 awaits。

我还在研究这个。 任何关于如何在这种情况下为 await 保持正确的线程关联的想法都将不胜感激。

最佳答案

这会有点长。首先，感谢 Matt Smith 和 Hans Passant 的想法，他们非常有帮助。

问题是由一位好老 friend 引起的，Application.DoEvents ，虽然以一种新颖的方式。汉斯有an excellent post关于为什么 DoEvents是一种邪恶。不幸的是，我无法避免使用 DoEvents在此控件中，由于遗留的非托管主机应用程序造成的同步 API 限制(更多信息在最后)。 我很清楚 DoEvents 的现有影响，但在这里我相信我们有一个新的:

在没有显式 WinForms 消息循环的线程上(即任何未输入 Application.Run 或 Form.ShowDialog 的线程)，调用 Application.DoEvents将用默认的 SynchronizationContext 替换当前的同步上下文, 提供 WindowsFormsSynchronizationContext.AutoInstall是true (默认情况下是这样)。

如果这不是错误，那么它就是一种非常令人不快的未记录行为，可能会严重影响某些组件开发人员。

这是一个重现该问题的简单控制台 STA 应用程序。 注意如何WindowsFormsSynchronizationContext被(错误地)替换为 SynchronizationContext在第一遍 Test并且不在第二遍中。

using System;
using System.Diagnostics;
using System.Threading;
using System.Threading.Tasks;
using System.Windows.Forms;

namespace ConsoleApplication
{
    class Program
    {
        [STAThreadAttribute]
        static void Main(string[] args)
        {
            Debug.Print("ApartmentState: {0}", Thread.CurrentThread.ApartmentState.ToString());
            Debug.Print("*** Test 1 ***");
            Test();
            SynchronizationContext.SetSynchronizationContext(null);
            WindowsFormsSynchronizationContext.AutoInstall = false;
            Debug.Print("*** Test 2 ***");
            Test();
        }

        static void DumpSyncContext(string id, string message, object ctx)
        {
            Debug.Print("{0}: {1} ({2})", id, ctx != null ? ctx.GetType().Name : "null", message);
        }

        static void Test()
        {
            Debug.Print("WindowsFormsSynchronizationContext.AutoInstall: {0}", WindowsFormsSynchronizationContext.AutoInstall);
            var ctx1 = SynchronizationContext.Current;
            DumpSyncContext("ctx1", "before setting up the context", ctx1);

            if (!(ctx1 is WindowsFormsSynchronizationContext))
                SynchronizationContext.SetSynchronizationContext(new WindowsFormsSynchronizationContext());

            var ctx2 = SynchronizationContext.Current;
            DumpSyncContext("ctx2", "before Application.DoEvents", ctx2);

            Application.DoEvents();

            var ctx3 = SynchronizationContext.Current;
            DumpSyncContext("ctx3", "after Application.DoEvents", ctx3);

            Debug.Print("ctx3 == ctx1: {0}, ctx3 == ctx2: {1}", ctx3 == ctx1, ctx3 == ctx2);
        }
    }
}

调试输出:

ApartmentState: STA
*** Test 1 ***
WindowsFormsSynchronizationContext.AutoInstall: True
ctx1: null (before setting up the context)
ctx2: WindowsFormsSynchronizationContext (before Application.DoEvents)
ctx3: SynchronizationContext (after Application.DoEvents)
ctx3 == ctx1: False, ctx3 == ctx2: False
*** Test 2 ***
WindowsFormsSynchronizationContext.AutoInstall: False
ctx1: null (before setting up the context)
ctx2: WindowsFormsSynchronizationContext (before Application.DoEvents)
ctx3: WindowsFormsSynchronizationContext (after Application.DoEvents)
ctx3 == ctx1: False, ctx3 == ctx2: True

It took some investigation of the Framework's implementation of Application.ThreadContext.RunMessageLoopInner and WindowsFormsSynchronizationContext.InstalIifNeeded/Uninstall to understand why exactly it happens. The condition is that the thread doesn't currently execute an Application message loop, as mentioned above. The relevant piece from RunMessageLoopInner:

if (this.messageLoopCount == 1)
{
    WindowsFormsSynchronizationContext.InstallIfNeeded();
}

然后WindowsFormsSynchronizationContext.InstallIfNeeded里面的代码/Uninstall这对方法没有正确保存/恢复线程的现有同步上下文。在这一点上，我不确定这是错误还是设计特性。

解决方案是禁用WindowsFormsSynchronizationContext.AutoInstall ，就这么简单:

struct SyncContextSetup
{
    public SyncContextSetup(bool autoInstall)
    {
        WindowsFormsSynchronizationContext.AutoInstall = autoInstall;
        SynchronizationContext.SetSynchronizationContext(new WindowsFormsSynchronizationContext());
    }
}

static readonly SyncContextSetup _syncContextSetup =
    new SyncContextSetup(autoInstall: false);

关于我为什么使用 Application.DoEvents 的几句话 这是在 UI 线程上运行的典型异步到同步桥接代码，使用嵌套消息循环。这是一种不好的做法，但旧版主机应用程序希望所有 API 同步完成。原问题描述here .稍后，我替换了 CoWaitForMultipleHandles与 Application.DoEvents 的组合/MsgWaitForMultipleObjects ，现在看起来像这样:

[已编辑] WaitWithDoEvents 的最新版本是here . [/EDITED]

想法是使用 .NET 标准机制发送消息，而不是依赖 CoWaitForMultipleHandles这样做。由于描述的 DoEvents 行为，那时我隐式地引入了同步上下文的问题。 .

遗留应用目前正在使用现代技术重写，控件也是如此。当前实现的目标是使用 Windows XP 的现有客户，他们由于我们无法控制的原因而无法升级。

最后，这是我在问题中提到的自定义等待程序的实现，作为缓解问题的一种选择。这是一次有趣的体验，而且很有效，但不能将其视为合适的解决方案。

/// <summary>
/// AwaitHelpers - custom awaiters
/// WithContext continues on the control's thread after await
/// E.g.: await TaskEx.Delay(1000).WithContext(this)
/// </summary>
public static class AwaitHelpers
{
    public static ContextAwaiter<T> WithContext<T>(this Task<T> task, Control control, bool alwaysAsync = false)
    {
        return new ContextAwaiter<T>(task, control, alwaysAsync);
    }

    // ContextAwaiter<T>
    public class ContextAwaiter<T> : INotifyCompletion
    {
        readonly Control _control;
        readonly TaskAwaiter<T> _awaiter;
        readonly bool _alwaysAsync;

        public ContextAwaiter(Task<T> task, Control control, bool alwaysAsync)
        {
            _awaiter = task.GetAwaiter();
            _control = control;
            _alwaysAsync = alwaysAsync;
        }

        public ContextAwaiter<T> GetAwaiter() { return this; }

        public bool IsCompleted { get { return !_alwaysAsync && _awaiter.IsCompleted; } }

        public void OnCompleted(Action continuation)
        {
            if (_alwaysAsync || _control.InvokeRequired)
            {
                Action<Action> callback = (c) => _awaiter.OnCompleted(c);
                _control.BeginInvoke(callback, continuation);
            }
            else
                _awaiter.OnCompleted(continuation);
        }

        public T GetResult()
        {
            return _awaiter.GetResult();
        }
    }
}

关于c# - 由非托管应用托管的托管组件中的 Await 和 SynchronizationContext，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19535147/