按类别查找文章：WPF

屏幕边缘上有趣的 1 个像素，看不见、摸不到

如果你的屏幕分辨率是 1920×1080，那么一个全屏的窗口程序尺寸是多少呢？想都不用想，是 1920×1080。

那么输入设备输入的坐标是多少呢？是 X∈[0, 1919] ？还是 X∈[1, 1920] ？还是 X∈[0, 1920] ？

鼠标输入与触摸输入

一个有趣的问题，因为 1920×1080 分辨率的屏幕，其横向只有 1920 个像素，也就是说如果需要区分一个像素，那么只需要 1920 个数值就够了。这意味着 X∈[0, 1919] 或者 X∈[1, 1920] 的取值范围就能表示横向的所有像素了。

那么实际上最左侧的点的输入数值是多少呢？最右侧的点的输入数值是多少呢？

我写了一个最大化全屏的程序专门用来测试鼠标和触摸输入的数值是多少。

▲ 在鼠标输入的情况下，最右侧其实是 1919（我的屏幕是 2560×1080，所以最右侧是 2559）

测量的时候，鼠标是直接往右移动到底，移到不能动为止。

那么在触摸输入的时候又如何？

▲ 在触摸输入的情况下，最右侧是 1920（我的屏幕是 2560×1080，所以最右侧是 2560）

测量的时候，是让手指近乎在屏幕外触摸，不断触摸到能够在屏幕上看到的最小或最大值为止。

有趣的 1 像素

发现上面实验中有趣的现象了吗？明明只有 1920×1080 的屏幕分辨率，窗口明明只有 1920×1080 那么大，鼠标下收到正常范围内的输入坐标，而触摸下我们能收到超出我们窗口大小 1 像素的触摸事件！

问题并没有完——

如果说，触摸给了你超出窗口大小的坐标，那么你能如何使用这个坐标呢？虽然程序里收到什么坐标都无所谓（至少不崩），但如果你真拿它来渲染，就会在屏幕之外。

更有趣的是，虽然你能收到这个“在屏幕边缘之外”的坐标，但这个消息并不总会发送到你的程序里。更多的时候，你的程序根本就不会收到这个触摸事件，于是我们也就不能在程序里面更新窗口上显示的坐标到 1920 了，就像鼠标一样。

于是，你可能遇到的问题是：

1. 如果你在屏幕的左侧边缘触摸，你的程序可以一直收到触摸事件，你能够得到正确的响应；
2. 如果你在屏幕的右侧边缘触摸，你将仅能偶尔收到零星的刚好超出窗口大小的触摸坐标，大多数时候收不到触摸事件，于是你可能无法获知用户在屏幕右侧边缘进行触摸。

防踩坑秘籍

林德熙小伙伴告诉我说可以特意把窗口的尺寸做大一个像素。我试过了，确实能够让触摸在整个屏幕上生效，但对于双屏用户来说，就能在另外一个屏幕上看到“露馅儿”了的窗口，对于我这种强迫症患者来说，显然是不能接受的。

我的建议是，并不需要对这种情况进行什么特殊的处理。

WPF 程序如何跨窗口/跨进程设置控件焦点

WPF 程序提供了 Focus 方法和 TraversalRequest 来在 WPF 焦点范围内转移焦点。但如果 WPF 窗口中嵌入了其他框架的 UI（比如另一个子窗口），那么就需要使用其他的方法来设置焦点了。

一个粗略的设置方法是，使用 Win32 API：

SetFocus(hwnd);

传入的是要设置焦点的窗口的句柄。

参考资料

• winapi - Win32: C++: How do I re-focus on Parent Window after clicking in a child window? - Stack Overflow

解决 WPF 嵌套的子窗口在改变窗口大小的时候闪烁的问题

因为 Win32 的窗口句柄是可以跨进程传递的，所以可以用来实现跨进程 UI。不过，本文不会谈论跨进程 UI 的具体实现，只会提及其实现中的一个重要缓解，使用子窗口的方式。

你有可能在使用子窗口之后，发现拖拽改变窗口大小的时候，子窗口中的内容不断闪烁。如果你也遇到了这样的问题，那么正好可以阅读本文来解决。

问题

你可以看一下下面的这张动图，感受一下窗口的闪烁：

实际上在拖动窗口的时候，是一直都在闪的，只是每次闪烁都非常快，截取 gif 的时候截不到。

如果你希望实际跑一跑项目看看，可以使用下面的代码：

• walterlv.demo/Walterlv.Demo.HwndWrapping/Walterlv.Demo.HwndWrapping at a88f81477756af2913349970ba2f0bbab01aaf88 · walterlv/walterlv.demo

我特地提取了一个提交下的代码，如果你要尝试，不能使用 master 分支，因为 master 分支修复了闪烁的问题。

后来使用 CreateWindowEx 创建了一个纯 Win32 窗口，这种闪烁现象更容易被截图：

解决

    public class HwndWrapper : HwndHost
    {
        protected override HandleRef BuildWindowCore(HandleRef hwndParent)
        {
            const int WS_CHILD = 0x40000000;
++          const int WS_CLIPCHILDREN = 0x02000000;
            var owner = ((HwndSource)PresentationSource.FromVisual(this)).Handle;

            var parameters = new HwndSourceParameters("demo")
            {
                ParentWindow = owner,
--              WindowStyle = (int)(WS_CHILD),
++              WindowStyle = (int)(WS_CHILD | WS_CLIPCHILDREN),
            };
            var source = new HwndSource(parameters);
            source.RootVisual = new ChildPage();
            return new HandleRef(this, source.Handle);
        }

        protected override void DestroyWindowCore(HandleRef hwnd)
        {
        }
    }

原因

正在探索……

参考资料

• wpf - Custom dwm drawn window frame flickers on resizing if the window contains a HwndHost element - Stack Overflow
• WPF多进程UI探索（Like Chrome） - 简书
• 关于WS_CLIPCHILDREN和WS_CLIPSIBLINGS的理解（个人认为还是相当全面的） - helloj2ee - 博客园

System.ComponentModel.Win32Exception (0x80004005): 无效的窗口句柄。

在 WPF 获取鼠标当前坐标的时候，可能会得到一个异常：System.ComponentModel.Win32Exception:“无效的窗口句柄。”。

本文解释此异常的原因和解决方法。

异常

获取鼠标当前相对于元素 element 的坐标的代码：

var point = Mouse.GetPosition(element);

或者，还有其他的代码：

var point1 = e.PointFromScreen(new Point());
var point2 = e.PointToScreen(new Point());

如果在按下窗口关闭按钮的时候调用以上代码，则会引发异常：

System.ComponentModel.Win32Exception (0x80004005): 无效的窗口句柄。
   at Point MS.Internal.PointUtil.ClientToScreen(Point pointClient, PresentationSource presentationSource)
   at Point System.Windows.Input.MouseDevice.GetScreenPositionFromSystem()

原因

将窗口上的点转换到控件上的点的方法是这样的：

/// <summary>
///     Convert a point from "client" coordinate space of a window into
///     the coordinate space of the screen.
/// </summary>
/// <SecurityNote>
///     SecurityCritical: This code causes eleveation to unmanaged code via call to GetWindowLong
///     SecurityTreatAsSafe: This data is ok to give out
///     validate all code paths that lead to this.
/// </SecurityNote>
[SecurityCritical, SecurityTreatAsSafe]
public static Point ClientToScreen(Point pointClient, PresentationSource presentationSource)
{
    // For now we only know how to use HwndSource.
    HwndSource inputSource = presentationSource as HwndSource;
    if(inputSource == null)
    {
        return pointClient;
    }
    HandleRef handleRef = new HandleRef(inputSource, inputSource.CriticalHandle);

    NativeMethods.POINT ptClient            = FromPoint(pointClient);
    NativeMethods.POINT ptClientRTLAdjusted = AdjustForRightToLeft(ptClient, handleRef);

    UnsafeNativeMethods.ClientToScreen(handleRef, ptClientRTLAdjusted);

    return ToPoint(ptClientRTLAdjusted);
}

最关键的是 UnsafeNativeMethods.ClientToScreen，此方法要求窗口句柄依然有效，然而此时窗口已经关闭，句柄已经销毁。

解决

WPF 高性能位图渲染 WriteableBitmap 及其高性能用法示例

WPF 渲染框架并没有对外提供多少可以完全控制渲染的部分，目前可以做的有：

• D3DImage，用来承载使用 DirectX 各个版本渲染内容的控件
• WriteableBitmap，通过一段内存空间来指定如何渲染一个位图的图片
• HwndHost，通过承载一个子窗口以便能叠加任何种类渲染的控件

本文将解释如何最大程度压榨 WriteableBitmap 在 WPF 下的性能。

如何使用 WriteableBitmap

创建一个新的 WPF 项目，然后我们在 MainWindow.xaml 中编写一点可以用来显示 WriteableBitmap 的代码：

<Window x:Class="Walterlv.Demo.HighPerformanceBitmap.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:local="clr-namespace:Walterlv.Demo.HighPerformanceBitmap"
        Title="WriteableBitmap - walterlv" SizeToContent="WidthAndHeight">
    <Grid>
        <Image x:Name="Image" Width="1280" Height="720" />
    </Grid>
</Window>

为了评估其性能，我决定绘制和渲染 4K 品质的位图，并通过以下步骤来评估：

1. 使用 CompositionTarget.Rendering 逐帧渲染以评估其渲染帧率
2. 使用 Benchmark 基准测试来测试内部各种不同方法的性能差异

于是，在 MainWindow.xaml.cs 中添加一些测试用的修改 WriteableBitmap 的代码：

using System;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Imaging;

namespace Walterlv.Demo.HighPerformanceBitmap
{
    public partial class MainWindow : Window
    {
        private readonly WriteableBitmap _bitmap;

        public MainWindow()
        {
            InitializeComponent();

            _bitmap = new WriteableBitmap(3840, 2160, 96.0, 96.0, PixelFormats.Pbgra32, null);
            Image.Source = _bitmap;
            CompositionTarget.Rendering += CompositionTarget_Rendering;
        }

        private void CompositionTarget_Rendering(object sender, EventArgs e)
        {
            var width = _bitmap.PixelWidth;
            var height = _bitmap.PixelHeight;

            _bitmap.Lock();

            // 在这里添加绘制位图的逻辑。

            _bitmap.AddDirtyRect(new Int32Rect(0, 0, width, height));
            _bitmap.Unlock();
        }
    }
}

注意，我留了一行注释说即将添加绘制位图的逻辑，接下来我们的主要内容将从此展开。

启用不安全代码

为了获取最佳性能，我们需要开启不安全代码。为此，你需要修改一下你的项目属性。

你可以阅读我的另一篇博客了解如何启用不安全代码：

• 如何在 .NET 项目中开启不安全代码（以便启用 unsafe fixed 等关键字） - walterlv

简单点说就是在你的项目文件中添加下面这一行：

    <Project Sdk="Microsoft.NET.Sdk">
      <PropertyGroup>
        <TargetFramework>netcoreapp3.0</TargetFramework>
++      <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
      </PropertyGroup>
    </Project>

启用帧率测试

接下来，我们需要添加一点点代码来评估 WriteableBitmap 的性能：

++  private readonly byte[] _empty4KBitmapArray = new byte[3840 * 2160 * 4];

--  private void CompositionTarget_Rendering(object sender, EventArgs e)
++  private unsafe void CompositionTarget_Rendering(object sender, EventArgs e)
    {
        var width = _bitmap.PixelWidth;
        var height = _bitmap.PixelHeight;

        _bitmap.Lock();

++      fixed (byte* ptr = _empty4KBitmapArray)
++      {
++          var p = new IntPtr(ptr);
++          Buffer.MemoryCopy(ptr, _bitmap.BackBuffer.ToPointer(), _empty4KBitmapArray.Length, _empty4KBitmapArray.Length);
++      }

        _bitmap.AddDirtyRect(new Int32Rect(0, 0, width, height));
        _bitmap.Unlock();
    }

嗯，就是将一个空的 4K 大小的数组中的内容复制到 WriteableBitmap 的位图缓存中。

4K 脏区

虽然我们看不到任何可变的修改，不过 WriteableBitmap 可不这么认为。因为我们调用了 AddDirtyRect 将整个位图空间都加入到了脏区中，这样 WPF 会重新渲染整幅位图。

Visual Studio 中看到的 CPU 占用率大约维持在 16% 左右（跟具体机器相关）；并且除了一开始启动的时候之外，完全没有 GC（这点很重要），内存稳定在一个值上不再变化。

也只有本文一开始提及的三种方法才可能做到渲染任何可能的图形的时候没有 GC

查看界面渲染帧率可以发现跑满 60 帧没有什么问题（跟具体机器相关）。

小脏区

现在，我们把脏区的区域缩小为 100*100，同样看性能数据。

--  _bitmap.AddDirtyRect(new Int32Rect(0, 0, width, height));
++  _bitmap.AddDirtyRect(new Int32Rect(0, 0, 100, 100));

可以发现 CPU 占用降低到一半（确实是大幅降低，但是跟像素数量并不成比例）；内存没有变化（废话，4K 图像是确定的）；帧率没有变化（废话，只要性能够，帧率就是满的）。

无脏区

现在，我们将脏区清零。

--  _bitmap.AddDirtyRect(new Int32Rect(0, 0, width, height));
++  _bitmap.AddDirtyRect(new Int32Rect(0, 0, 0, 0));

在完全没有脏区的时候，CPU 占用直接降为 0，这个性能提升还是非常恐怖的。

不渲染

如果我们不把 WriteableBitmap 设置为 Image 的 Source 属性，那么无论脏区多大，CPU 占用都是 0。

脏区大小与 CPU 占用率之间的关系

从前面的测试中我们可以发现，脏区的大小在 WriteableBitmap 的渲染里占了绝对的耗时。因此，我把脏区大小与 CPU 占用率之间的关系用图表的形式贴出来，这样可以直观地理解其性能差异。

需要注意，CPU 占用率与机器性能强相关，因此其绝对占用没有意义，但相对大小则有参考价值。

根据这张表我么可以得出：

• 脏区渲染是 CPU 占用的最大瓶颈（因为没有脏区仅剩内存拷贝的时候 CPU 占用为 0%）

但是有一个需要注意的信息是——虽然 CPU 占用率受脏区影响非常大，但主线程却几乎没有消耗 CPU 占用。此占用基本上全是渲染线程的事。

如果我们分析主线程的性能分布，可以发现内存拷贝现在是性能瓶颈：

后面我们会提到 WriteableBitmap 的渲染原理，也会说到这一点。

启用基准测试（Benchmark）

不过，由于内存数据的拷贝和脏区渲染实际上可以分开到两个不同的线程，如果这两者不同步执行（可能执行次数还有差异）的情况下，内存拷贝也可能成为性能瓶颈的一部分。

于是我将不同的内存拷贝方法进行一个基准测试，便于大家评估使用哪种方法来为 WriteableBitmap 提供渲染数据。

使用 CopyMemory 拷贝内存

++  [Benchmark(Description = "CopyMemory")]
++  [Arguments(3840, 2160)]
++  [Arguments(100, 100)]
    public unsafe void CopyMemory(int width, int height)
    {
        _bitmap.Lock();

++      fixed (byte* ptr = _empty4KBitmapArray)
++      {
++          var p = new IntPtr(ptr);
++          CopyMemory(_bitmap.BackBuffer, new IntPtr(ptr), (uint)_empty4KBitmapArray.Length);
++      }

        _bitmap.AddDirtyRect(new Int32Rect(0, 0, width, height));
        _bitmap.Unlock();
    }

[DllImport("kernel32.dll")]
private static extern void CopyMemory(IntPtr destination, IntPtr source, uint length);

使用 MoveMemory 移动内存

++  [Benchmark(Description = "RtlMoveMemory")]
++  [Arguments(3840, 2160)]
++  [Arguments(100, 100)]
    public unsafe void RtlMoveMemory(int width, int height)
    {
        _bitmap.Lock();

++      fixed (byte* ptr = _empty4KBitmapArray)
++      {
++          var p = new IntPtr(ptr);
++          MoveMemory(_bitmap.BackBuffer, new IntPtr(ptr), (uint)_empty4KBitmapArray.Length);
++      }

        _bitmap.AddDirtyRect(new Int32Rect(0, 0, width, height));
        _bitmap.Unlock();
    }

    [DllImport("kernel32.dll", EntryPoint = "RtlMoveMemory")]
    private static extern void MoveMemory(IntPtr dest, IntPtr src, uint count);

使用 Buffer.MemoryCopy 拷贝内存

需要注意，Buffer.MemoryCopy 是 .NET Framework 4.6 才引入的 API，在 .NET Framework 后续版本以及 .NET Core 的所有版本才可以使用，更旧版本的 .NET Framework 没有这个 API。

++  [Benchmark(Baseline = true, Description = "Buffer.MemoryCopy")]
++  [Arguments(3840, 2160)]
++  [Arguments(100, 100)]
    public unsafe void BufferMemoryCopy(int width, int height)
    {
        _bitmap.Lock();

++      fixed (byte* ptr = _empty4KBitmapArray)
++      {
++          var p = new IntPtr(ptr);
++          Buffer.MemoryCopy(ptr, _bitmap.BackBuffer.ToPointer(), _empty4KBitmapArray.Length, _empty4KBitmapArray.Length);
++      }

        _bitmap.AddDirtyRect(new Int32Rect(0, 0, width, height));
        _bitmap.Unlock();
    }

自己写 for 循环

++  [Benchmark(Description = "for for")]
++  [Arguments(3840, 2160)]
++  [Arguments(100, 100)]
    public unsafe void ForForCopy(int width, int height)
    {
        _bitmap.Lock();

++      var buffer = (byte*)_bitmap.BackBuffer.ToPointer();
++      for (var j = 0; j < height; j++)
++      {
++          for (var i = 0; i < width; i++)
++          {
++              var pixel = buffer + j * width * 4 + i * 4;
++              *pixel = 0xff;
++              *(pixel + 1) = 0x7f;
++              *(pixel + 2) = 0x00;
++              *(pixel + 3) = 0xff;
++          }
++      }

        _bitmap.AddDirtyRect(new Int32Rect(0, 0, width, height));
        _bitmap.Unlock();
    }

基准测试数据

我们跑一次基准测试：

可以发现：

1. CopyMemory 和 RtMoveMemory 性能是最好的，其性能差不多；
2. 自己写循环拷贝内存的性能是最差的；
3. 如果 WriteableBitmap 不渲染，那么无论设置多大的脏区都不会对性能有任何影响。

结论和使用建议

综合前面两者的结论，我们可以发现：

1. WriteableBitmap 的性能瓶颈源于对脏区的重新渲染
   • 脏区为 0 或者不在可视化树渲染，则不消耗性能
   • 只要有脏区，渲染过程就会开始成为性能瓶颈
     • CPU 占用基础值就很高了
     • 脏区越大，CPU 占用越高，但增幅不大
2. 内存拷贝不是 WriteableBitmap 的性能瓶颈
   • 建议使用 Windows API 或者 .NET API 来拷贝内存（而不是自己写）

另外，如果你有一些特殊的应用场景，可以适当调整下自己写代码的策略：

• 如果你希望有较大脏区的情况下降低 CPU 占用，可以考虑降低 WriteableBitmap 脏区的刷新率
• 如果你希望 WriteableBitmap 有较低的渲染延迟，则考虑减小脏区

WriteableBitmap 渲染原理

在调用 WriteableBitmap 的 AddDirtyRect 方法的时候，实际上是调用 MILSwDoubleBufferedBitmap.AddDirtyRect，这是 WPF 专门为 WriteableBitmap 而提供的非托管代码的双缓冲位图的实现。

在 WriteableBitmap 内部数组修改完毕之后，需要调用 Unlock 来解锁内部缓冲区的访问，这时会提交所有的修改。接下来的渲染都交给了 MediaContext，用来完成双缓冲位图的渲染。

private void SubscribeToCommittingBatch()
{
    // Only subscribe the the CommittingBatch event if we are on-channel.
    if (!_isWaitingForCommit)
    {
        MediaContext mediaContext = MediaContext.From(Dispatcher);
        if (_duceResource.IsOnChannel(mediaContext.Channel))
        {
            mediaContext.CommittingBatch += CommittingBatchHandler;
            _isWaitingForCommit = true;
        }
    }
}

在上面的 CommittingBatchHandler 中，将渲染指令发送到了渲染线程。

channel.SendCommand((byte*)&command, sizeof(DUCE.MILCMD_DOUBLEBUFFEREDBITMAP_COPYFORWARD));

前面我们通过脏区大小可以得出内存拷贝不是 CPU 占用率的瓶颈，脏区大小才是，不过是渲染线程在占用这 CPU 而不是主线程。但是内存拷贝却成为了主线程的瓶颈（当然前面我们给出了数据，实际上非常小）。所以如果试图分析这么高 CPU 的占用，会发现并不能从主线程上调查得出符合预期的结论（因为即便你完全干掉了内存拷贝，CPU 占用依然是这么高）。

WPF 制作高性能的透明背景异形窗口（使用 WindowChrome 而不要使用 AllowsTransparency=True）

在 WPF 中，如果想做一个背景透明的异形窗口，基本上都要设置 WindowStyle="None"、AllowsTransparency="True" 这两个属性。如果不想自定义窗口样式，还需要设置 Background="Transparent"。这样的设置会让窗口变成 Layered Window，WPF 在这种类型窗口上的渲染性能是非常糟糕的。

本文介绍如何使用 WindowChrome 而不设置 AllowsTransparency="True" 制作背景透明的异形窗口，这可以避免异形窗口导致的低渲染性能。

背景透明的异形窗口

如下是一个背景透明异形窗口的示例：

此窗口包含很大的圆角，还包含 DropShadowEffect 制作的阴影效果。对于非透明窗口来说，这是不可能实现的。

如何实现

要实现这种背景透明的异形窗口，需要为窗口设置以下三个属性：

• WindowStyle="None"
• ResizeMode="CanMinimize" 或 ResizeMode="NoResize"
• WindowChrome.GlassFrameThickness="-1" 或设置为其他较大的正数（可自行尝试设置之后的效果）

如下就是一个最简单的例子，最关键的三个属性我已经高亮标记出来了。

    <Window x:Class="Walterlv.Demo.MainWindow"
            xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
            xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
++          WindowStyle="None" ResizeMode="CanMinimize"
            Title="walterlv demo" Height="450" Width="800">
++      <WindowChrome.WindowChrome>
++          <WindowChrome GlassFrameThickness="-1" />
++      </WindowChrome.WindowChrome>
        <Window.Template>
            <ControlTemplate TargetType="Window">
                <Border Padding="64" Background="Transparent">
                    <Border CornerRadius="16" Background="White">
                        <Border.Effect>
                            <DropShadowEffect BlurRadius="64" />
                        </Border.Effect>
                        <ContentPresenter ClipToBounds="True" />
                    </Border>
                </Border>
            </ControlTemplate>
        </Window.Template>
        <Grid>
            <TextBlock FontSize="20" Foreground="#0083d0"
                   TextAlignment="Center" VerticalAlignment="Center">
                <Run Text="欢迎访问吕毅的博客" />
                <LineBreak />
                <Run Text="blog.walterlv.com" FontSize="64" FontWeight="Light" />
            </TextBlock>
        </Grid>
    </Window>

网上流传的主流方法

在网上流传的主流方法中，AllowsTransparency="True" 都是一个必不可少的步骤，另外也需要 WindowStyle="None"。但是我一般都会极力反对大家这么做，因为 AllowsTransparency="True" 会造成很严重的性能问题。

如果你有留意到我的其他博客，你会发现我定制窗口样式的时候都在极力避开设置此性能极差的属性：

• WPF 使用 WindowChrome，在自定义窗口标题栏的同时最大程度保留原生窗口样式（类似 UWP/Chrome）

性能对比

既然特别说到性能，那也是口说无凭，我们要拿出数据来说话。

以下是我用来测试渲染性能所使用的例子：

相比于上面的例子来说，主要就是加了背景动画效果，这可以用来测试帧率。

    <Window x:Class="Walterlv.Demo.MainWindow"
            xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
            xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
            WindowStyle="None" ResizeMode="CanMinimize"
            Title="walterlv demo" Height="450" Width="800">
        <WindowChrome.WindowChrome>
            <WindowChrome GlassFrameThickness="-1" />
        </WindowChrome.WindowChrome>
        <Window.Template>
            <ControlTemplate TargetType="Window">
                <Border Padding="64" Background="Transparent">
                    <Border CornerRadius="16" Background="White">
                        <Border.Effect>
                            <DropShadowEffect BlurRadius="64" />
                        </Border.Effect>
                        <ContentPresenter ClipToBounds="True" />
                    </Border>
                </Border>
            </ControlTemplate>
        </Window.Template>
        <Grid>
++          <Rectangle x:Name="BackgroundRectangle" Margin="0 16" Fill="#d0d1d6">
++              <Rectangle.RenderTransform>
++                  <TranslateTransform />
++              </Rectangle.RenderTransform>
++              <Rectangle.Triggers>
++                  <EventTrigger RoutedEvent="FrameworkElement.Loaded">
++                      <BeginStoryboard>
++                          <BeginStoryboard.Storyboard>
++                              <Storyboard RepeatBehavior="Forever">
++                                  <DoubleAnimation Storyboard.TargetName="BackgroundRectangle"
++                                                   Storyboard.TargetProperty="(UIElement.RenderTransform).(TranslateTransform.X)"
++                                                   From="800" To="-800" />
++                              </Storyboard>
++                          </BeginStoryboard.Storyboard>
++                      </BeginStoryboard>
++                  </EventTrigger>
++              </Rectangle.Triggers>
++          </Rectangle>
            <TextBlock FontSize="20" Foreground="#0083d0"
                   TextAlignment="Center" VerticalAlignment="Center">
                <Run Text="欢迎访问吕毅的博客" />
                <LineBreak />
                <Run Text="blog.walterlv.com" FontSize="64" FontWeight="Light" />
            </TextBlock>
        </Grid>
    </Window>

那么性能数据表现如何呢？我们让这个窗口在 2560×1080 的屏幕上全屏渲染，得出以下数据：

另外，对于显存的使用，如果我在 7680×2160 的屏幕上全屏渲染，WindowChrome 方案依然保持在 80+MB，而 AllowsTransparency 已经达到惊人的 800+MB 了。

可见，对于渲染性能，使用 WindowChrome 制作的背景透明异形窗口性能完虐使用 AllowsTransparency 制作的背景透明异形窗口，实际上跟完全没有设置透明窗口的性能保持一致。

功能对比

既然 WindowChrome 方法在性能上完虐网上流传的设置 AllowsTransparency 方法，那么功能呢？

值得注意的是，由于在使用 WindowChrome 制作透明窗口的时候设置了 ResizeMode="None"，所以你拖动窗口在屏幕顶部和左右两边的时候，Windows 不会再帮助你最大化窗口或者靠边停靠窗口，于是你需要自行处理。不过窗口的标题栏拖动功能依然保留了下来，标题栏上的右键菜单也是可以继续使用的。

表格中：

• 保留 表示此功能无需任何处理即可继续支持
• 自行实现 表示此功能已消失，但仅需要一两行代码即可补回功能
• 丢失 表示此功能已消失，如需实现需要编写大量代码

另外，以上表格仅针对鼠标操作窗口。如果算上使用触摸来操作窗口，那么所有标记为 自行实现 的都将变为 丢失。因为虽然你可以一句话补回功能，但在触摸操作下各种 Bug，你解不完……

• WPF 程序无法触摸操作？我们一起来找原因和解决方法！

这两种实现的窗口之间还有一些功能上的区别：

什么是模态窗口？本文带你了解模态窗口的本质

做 Windows 桌面应用开发的小伙伴们对“模态窗口”（Modal Dialog）一定不陌生。如果你希望在模态窗口之上做更多的事情，或者自己实现一套模态窗口类似的机制，那么你可能需要了解模态窗口的本质。

本文不会太深，只是从模态窗口一词出发，抵达大家都熟知的一些知识为止。

开发中的模态窗口

在各种系统、语言和框架中，只要有用户可以看见的界面，都存在模态窗口的概念。从交互层面来说，它的形式是在保留主界面作为环境来显示的情况下，打开一个新的界面，用户只能在新的界面上操作，完成或取消后才能返回主界面。从作用上来说，通常是要求用户必须提供某些信息后才能继续操作，或者单纯只是为了广告。

模态窗口的三个特点

如果你希望自己搞一套模态窗口出来，那么只需要满足这三点即可。你可以随便加戏但那都无关紧要。

1. 保留主界面显示的同时，禁用主界面的用户交互；
2. 显示子界面，主界面在子界面操作完成后返回；
3. 当用户试图跳过子界面的交互的时候进行强提醒。

拿 Windows 系统中的模态对话框为例子，大概就像下面这两张图片这样：

有一个小的子界面盖住了主界面，要求用户必须进行选择。Windows 系统设置因为让背景变暗了，所以用户肯定会看得到需要进行的交互；而任务管理器没有让主界面变暗，所以用户在操作子界面的时候，模态窗口的边框和标题栏闪烁以提醒用户注意。

实现模态窗口

对于 Windows 操作系统来说，模态窗口并不是一个单一的概念，你并不能仅通过一个 API 调用就完成显示模态窗口，你需要在不同的时机调用不同的 API 来完成一个模态窗口。如果要完整实现一个自己的模态窗口，则需要编写实现以上三个特点的代码。

当然，你可能会发现实际上你显示一个模态窗口仅仅一句话调用就够了，那是因为你所用的应用程序框架帮你完成了模态窗口的一系列机制。

关于 WPF 框架是如何实现模态窗口的，可以阅读：直击本质：WPF 框架是如何实现模态窗口的

关于如何自己实现一个跨越线程/进程边界的模态窗口，可以阅读：实现 Windows 系统上跨进程/跨线程的模态窗口

如果你希望定制以上第三个特点中强提醒的动画效果，可以阅读：WPF window 子窗口反馈效果（抖动/阴影渐变) - 唐宋元明清2188 - 博客园。

API 调用

为了在 Windows 上实现模态窗口，需要一些 Win32 API 调用（当然，框架够用的话直接用框架就好）。

禁用主窗口

我们需要使用到 BOOL EnableWindow(HWND hWnd, BOOL bEnable); 来启用与禁用某个窗口。

EnableWindow(hWnd, false);
try
{
    // 模态显示一个窗口。
}
finally
{
    EnableWindow(hWnd, true);
}

[DllImport("user32")]
private static extern bool EnableWindow(IntPtr hwnd, bool bEnable);

阻塞代码等待操作完成

因为 async/await 的出现，阻塞其实可以使用 await 来实现。虽然这不是真正的阻塞，但可以真实反应出“异步”这个过程，也就是虽然这里在等待，但实际上依然能够继续在同一个线程响应用户的操作。

UWP 中的新 API 当然已经都是使用 async/await 来实现模态等待了，不过 WPF/Windows Forms 比较早，只能使用 Dispatcher 线程模型来实现模态等待。

于是我们可以考虑直接使用现成的 Dispatcher 线程模型来完成等待，方法是调用下面两个当中的任何一个：

• Window.ShowDialog 也就是直接使用窗口原生的模态
• Dispatcher.PushFrame 新开一个消息循环以阻塞当前代码的同时继续响应 UI 交互

上面 Window.ShowDialog 的本质也是在调用 Dispatcher.PushFrame，详见：

• 直击本质：WPF 框架是如何实现模态窗口的

关于 PushFrame 新开消息循环阻塞的原理可以参考：

• 深入了解 WPF Dispatcher 的工作原理（PushFrame 部分） - walterlv

当然，还有其他可以新开消息循环的方法。

进行 UI 强提醒

由于我们一开始禁用了主窗口，所以如果用户试图操作主窗口是不会有效果的。然而如果用户不知道当前显示了一个模态窗口需要操作，那么给出提醒也是必要的。

简单的在 UI 上的提醒是最简单的了，比如：

• 将主界面变暗（UWP 应用，Web 应用喜欢这么做）
• 将主界面变模糊（iOS 应用喜欢这么做）
• 在模态窗口上增加一个很厚重的阴影（Android 应用喜欢这么做）

然而 Windows 和 Mac OS 这些古老的系统由于兼容性负担不能随便那么改，于是需要有其他的提醒方式。

Windows 采用的方式是让标题栏闪烁，让阴影闪烁。

而这些特效的处理，来自于子窗口需要处理一些特定的消息 WM_SETCURSOR。

详见：WPF window 子窗口反馈效果（抖动/阴影渐变) - 唐宋元明清2188 - 博客园

通常你不需要手工处理这些消息，但是如果你完全定制了窗口样式，则可能需要自行做一个这样的模态窗口提醒效果。

直击本质：WPF 框架是如何实现模态窗口的

想知道你在 WPF 编写 Window.ShowDialog() 之后，WPF 框架是如何帮你实现模态窗口的吗？

本文就带你来了解这一些。

Window.ShowDialog

WPF 显示模态窗口的方法就是 Window.ShowDialog，因此我们直接进入这个方法查看。由于 .NET Core 版本的 WPF 已经开源，我们会使用 .NET Core 版本的 WPF 源代码。

Window.ShowDialog 的源代码可以在这里查看：

• Window.cs

这个方法非常长，所以我只把其中与模态窗口最关键的代码和相关注释留下，其他都删除（这当然是不可编译的）：

public Nullable<bool> ShowDialog()
{
    // NOTE:
    // _threadWindowHandles is created here.  This reference is nulled out in EnableThreadWindows
    // when it is called with a true parameter.  Please do not null it out anywhere else.
    // EnableThreadWindow(true) is called when dialog is going away.  Once dialog is closed and
    // thread windows have been enabled, then there no need to keep the array list around.
    // Please see BUG 929740 before making any changes to how _threadWindowHandles works.
    _threadWindowHandles = new ArrayList();
    //Get visible and enabled windows in the thread
    // If the callback function returns true for all windows in the thread, the return value is true.
    // If the callback function returns false on any enumerated window, or if there are no windows
    // found in the thread, the return value is false.
    // No need for use to actually check the return value.
    UnsafeNativeMethods.EnumThreadWindows(SafeNativeMethods.GetCurrentThreadId(),
                                            new NativeMethods.EnumThreadWindowsCallback(ThreadWindowsCallback),
                                            NativeMethods.NullHandleRef);
    //disable those windows
    EnableThreadWindows(false);

    try
    {
        _showingAsDialog = true;
        Show();
    }
    catch
    {
        // NOTE:
        // See BUG 929740.
        // _threadWindowHandles is created before calling ShowDialog and is deleted in
        // EnableThreadWindows (when it's called with true).
        //
        // Window dlg = new Window();
        // Button b = new button();
        // b.OnClick += new ClickHandler(OnClick);
        // dlg.ShowDialog();
        //
        //
        // void OnClick(...)
        // {
        //      dlg.Close();
        //      throw new Exception();
        // }
        //
        //
        // If above code is written, then we get inside this exception handler only after the dialog
        // is closed.  In that case all the windows that we disabled before showing the dialog have already
        // been enabled and _threadWindowHandles set to null in EnableThreadWindows.  Thus, we don't
        // need to do it again.
        //
        // In any other exception cases, we get in this handler before Dialog is closed and thus we do
        // need to enable all the disable windows.
        if (_threadWindowHandles != null)
        {
            // Some exception case. Re-enable the windows that were disabled
            EnableThreadWindows(true);
        }
    }
}

觉得代码还是太长？不要紧，我再简化一下：

1. EnumThreadWindows 获取当前线程的所有窗口
2. 把当前线程中的所有窗口都禁用掉（用的是 Win32 API 的禁用哦，这不会导致窗口内控件的样式变为禁用状态）
3. 将窗口显示出来（如果出现异常，则还原之前禁用的窗口）

可以注意到禁用掉的窗口是“当前线程”的哦。

ShowHelper

接下来的重点方法是 Window.ShowDialog 中的那句 Show()。在 Show() 之前设置了 _showingAsDialog 为 true，于是这里会调用 ShowHelper 方法并传入 true。

下面的代码也是精简后的 ShowHelper 方法：

private object ShowHelper(object booleanBox)
{
    try
    {
        // tell users we're going modal
        ComponentDispatcher.PushModal();

        _dispatcherFrame = new DispatcherFrame();
        Dispatcher.PushFrame(_dispatcherFrame);
    }
    finally
    {
        // tell users we're going non-modal
        ComponentDispatcher.PopModal();
    }
}

可以看到，重点是 PushModal、PopModal 以及 PushFrame。

PushFrame 的效果就是让调用 ShowDialog 的代码看起来就像阻塞了一样（实际上就是阻塞了，只不过开了新的消息循环看起来 UI 不卡）。

关于 PushFrame 为什么能够“阻塞”你的代码的同时还能继续响应 UI 操作的原理，可以阅读：

• 深入了解 WPF Dispatcher 的工作原理（PushFrame 部分） - walterlv

那么 ComponentDispatcher.PushModal 和 ComponentDispatcher.PopModal 呢？可以在这里（ComponentDispatcherThread.cs）看它的代码，实际上是为了模态计数以及引发事件的，对模态的效果没有本质上的影响。

使用 SetWindowCompositionAttribute 来控制程序的窗口边框和背景（可以做 Acrylic 亚克力效果、模糊效果、主题色效果等）

Windows 系统中有一个没什么文档的 API，SetWindowCompositionAttribute，可以允许应用的开发者将自己窗口中的内容渲染与窗口进行组合。这可以实现很多系统中预设的窗口特效，比如 Windows 7 的毛玻璃特效，Windows 8/10 的前景色特效，Windows 10 的模糊特效，以及 Windows 10 1709 的亚克力（Acrylic）特效。而且这些组合都发生在 dwm 进程中，不会额外占用应用程序的渲染性能。

本文介绍 SetWindowCompositionAttribute 可以实现的所有效果。你可以通过阅读本文了解到与系统窗口可以组合渲染到哪些程度。

试验用的源代码

本文将创建一个简单的 WPF 程序来验证 SetWindowCompositionAttribute 能达到的各种效果。你也可以不使用 WPF，得到类似的效果。

简单的项目文件结构是这样的：

• [项目] Walterlv.WindowComposition
  • App.xaml
  • App.xaml.cs
  • MainWindow.xaml
  • MainWindow.xaml.cs
  • WindowAccentCompositor

其中，App.xaml 和 App.xaml.cs 保持默认生成的不动。

为了验证此 API 的效果，我需要将 WPF 主窗口的背景色设置为纯透明或者 null，而设置 ControlTemplate 才能彻彻底底确保所有的样式一定是受我们自己控制的，我们在 ControlTemplate 中没有指定任何可以显示的内容。MainWindow.xaml 的全部代码如下：

<Window x:Class="Walterlv.WindowComposition.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="欢迎访问吕毅的博客：blog.walterlv.com" Height="450" Width="800">
    <Window.Template>
        <ControlTemplate TargetType="Window">
            <AdornerDecorator>
                <ContentPresenter />
            </AdornerDecorator>
        </ControlTemplate>
    </Window.Template>
    <!-- 我们注释掉 WindowChrome，是因为即将验证 WindowChrome 带来的影响。 -->
    <!--<WindowChrome.WindowChrome>
        <WindowChrome GlassFrameThickness="-1" />
    </WindowChrome.WindowChrome>-->
    <Grid>
    </Grid>
</Window>

而 MainWindow.xaml.cs 中，我们简单调用一下我们即将写的调用 SetWindowCompositionAttribute 的类型。

using System.Windows;
using System.Windows.Media;
using Walterlv.Windows.Effects;

namespace Walterlv.WindowComposition
{
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
            var compositor = new WindowAccentCompositor(this);
            compositor.Composite(Color.FromRgb(0x18, 0xa0, 0x5e));
        }
    }
}

还剩下一个 WindowAccentCompositor.cs 文件，因为比较长放到博客里影响阅读，所以建议前往这里查看：

• Walterlv.Packages/WindowAccentCompositor.cs at master · walterlv/Walterlv.Packages

而其中对我们最终渲染效果有影响的就是 AccentPolicy 类型的几个属性。其中 AccentState 属性是下面这个枚举，而 GradientColor 将决定窗口渲染时叠加的颜色。

private enum AccentState
{
    ACCENT_DISABLED = 0,
    ACCENT_ENABLE_GRADIENT = 1,
    ACCENT_ENABLE_TRANSPARENTGRADIENT = 2,
    ACCENT_ENABLE_BLURBEHIND = 3,
    ACCENT_ENABLE_ACRYLICBLURBEHIND = 4,
    ACCENT_INVALID_STATE = 5,
}

影响因素

经过试验，对最终显示效果有影响的有这些：

• 选择的 AccentState 枚举值
• 使用的 GradientColor 叠加色
• 是否使用 WindowChrome 让客户区覆盖非客户区
• 目标操作系统（Windows 7/8/8.1/10）

使用 WindowChrome，你可以用你自己的 UI 覆盖掉系统的 UI 窗口样式。关于 WindowChrome 让客户区覆盖非客户区的知识，可以阅读：

• [WPF 自定义控件] Window（窗体）的 UI 元素及行为 - dino.c - 博客园

需要注意的是，WindowChrome 的 GlassFrameThickness 属性可以设置窗口边框的粗细，设置为 0 将导致窗口没有阴影，设置为负数将使得整个窗口都是边框。

排列组合

我们依次来看看效果。

AccentState=ACCENT_DISABLED

使用 ACCENT_DISABLED 时，GradientColor 叠加色没有任何影响，唯一影响渲染的是 WindowChrome 和操作系统。

不使用 WindowChrome，在 Windows 10 上：

不使用 WindowChrome 在 Windows 7 上：

在 Windows 10 上，使用 WindowChrome：

<WindowChrome.WindowChrome>
    <WindowChrome />
</WindowChrome.WindowChrome>

在 Windows 7 上，使用 WindowChrome：

当然，以上边框比较细，跟系统不搭，可以设置成其他值：

在 Windows 10 上，使用 WindowChrome 并且 GlassFrameThickness 设置为 -1：

<WindowChrome.WindowChrome>
    <WindowChrome GlassFrameThickness="-1" />
</WindowChrome.WindowChrome>

而在 Windows 7 上，这就是非常绚丽的全窗口的 Aero 毛玻璃特效：

AccentState=ACCENT_ENABLE_GRADIENT

使用 ACCENT_DISABLED 时，GradientColor 叠加色会影响到最终的渲染效果。

还记得我们前面叠加的颜色是什么吗？

接下来别忘了然后把它误以为是我系统的主题色哦！

不使用 WindowChrome，在 Windows 10 上：

另外，你会注意到左、下、右三个方向上边框会深一些。那是 Windows 10 的窗口阴影效果，因为实际上 Windows 10 叠加的阴影也是窗口区域的一部分，只是一般人看不出来而已。我们叠加了颜色之后，这里就露馅儿了。

另外，这个颜色并不是我们自己的进程绘制的哦，是 dwm 绘制的颜色。

如果不指定 GradientColor 也就是保持为 0，你将看到上面绿色的部分全是黑色的；嗯，包括阴影的部分……

不使用 WindowChrome 在 Windows 7 上：

可以看出，在 Windows 7 上，GradientColor 被无视了。

而使用 WindowChrome 在 Windows 10 上，则可以得到整个窗口的叠加色：

<WindowChrome.WindowChrome>
    <WindowChrome GlassFrameThickness="16 48 16 16" />
</WindowChrome.WindowChrome>

可以注意到，窗口获得焦点的时候，整个窗口都是叠加色；而窗口失去焦点的时候，指定了边框的部分颜色会更深（换其他颜色叠加可以看出来是叠加了半透明黑色）。

如果你希望失去焦点的时候，边框部分不要变深，请将边框设置为 -1：

<WindowChrome.WindowChrome>
    <WindowChrome GlassFrameThickness="-1" />
</WindowChrome.WindowChrome>

使用 WindowChrome 在 Windows 7 上，依然没有任何叠加色的效果：

AccentState=ACCENT_ENABLE_TRANSPARENTGRADIENT

使用 ACCENT_ENABLE_TRANSPARENTGRADIENT 时，GradientColor 叠加色没有任何影响，唯一影响渲染的是 WindowChrome 和操作系统。

不使用 WindowChrome，在 Windows 10 上：

依然左、下、右三个方向上边框会深一些，那是 Windows 10 的窗口阴影效果。

不使用 WindowChrome 在 Windows 7 上：

GradientColor 也是被无视的，而且效果跟之前一样。

使用 WindowChrome 在 Windows 10 上，在获得焦点的时候整个背景是系统主题色；而失去焦点的时候是灰色，但边框部分是深色。

依然可以将边框设置为 -1 使得边框不会变深：

使用 WindowChrome 在 Windows 7 上，依然是老样子：

AccentState=ACCENT_ENABLE_BLURBEHIND

ACCENT_ENABLE_BLURBEHIND 可以在 Windows 10 上做出模糊效果，就跟 Windows 10 早期版本的模糊效果是一样的。你可以看我之前的一篇博客，那时亚克力效果还没出来：

• 在 Windows 10 上为 WPF 窗口添加模糊特效（就像开始菜单和操作中心那样） - walterlv

使用 ACCENT_ENABLE_BLURBEHIND 时，GradientColor 叠加色没有任何影响，唯一影响渲染的是 WindowChrome 和操作系统。

在 Windows 10 上，没有使用 WindowChrome：

你可能需要留意一下那个“诡异”的模糊范围，你会发现窗口的阴影外侧也是有模糊的！！！你能忍吗？肯定不能忍，所以还是乖乖使用 WindowChrome 吧！

在 Windows 7 上，没有使用 WindowChrome，效果跟其他值一样，依然没有变化：

在 Windows 10 上，使用 WindowChrome：

使用 WindowChrome 在 Windows 7 上，依然是老样子：

AccentState=ACCENT_ENABLE_ACRYLICBLURBEHIND

从 Windows 10 (1803) 开始，Win32 程序也能添加亚克力效果了，因为 SetWindowCompositionAttribute 的参数枚举新增了 ACCENT_ENABLE_ACRYLICBLURBEHIND。

亚克力效果相信大家不陌生，那么在 Win32 应用程序里面使用的效果是什么呢？

不使用 WindowChrome，在 Windows 10 上：

咦！等等！这不是跟之前一样吗？

嗯，下面就是不同了，亚克力效果支持与半透明的 GradientColor 叠加，所以我们需要将传入的颜色修改为半透明：

    var compositor = new WindowAccentCompositor(this);
--  compositor.Composite(Color.FromRgb(0x18, 0xa0, 0x5e));
++  compositor.Composite(Color.FromArgb(0x3f, 0x18, 0xa0, 0x5e));

那么如果改为全透明会怎么样呢？

不幸的是，完全没有效果！！！

    var compositor = new WindowAccentCompositor(this);
--  compositor.Composite(Color.FromRgb(0x18, 0xa0, 0x5e));
++  compositor.Composite(Color.FromArgb(0x00, 0x18, 0xa0, 0x5e));

接下来是使用 WindowChrome 时：

<WindowChrome.WindowChrome>
    <WindowChrome GlassFrameThickness="16 48 16 16" />
</WindowChrome.WindowChrome>

然而周围有一圈偏白色的渐变是什么呢？那个其实是 WindowChrome 设置的边框白，被亚克力效果模糊后得到的混合效果。

所以，如果要获得全窗口的亚克力效果，请将边框设置成比较小的值：

<WindowChrome.WindowChrome>
    <WindowChrome GlassFrameThickness="0 1 0 0" />
</WindowChrome.WindowChrome>

记得不要像前面的那些效果一样，如果设置成 -1，你将获得纯白色与设置的 Gradient 叠加色的亚克力特效，是个纯色：

你可以将叠加色的透明度设置得小一些，这样可以看出叠加的颜色：

    var compositor = new WindowAccentCompositor(this);
--  compositor.Composite(Color.FromRgb(0x18, 0xa0, 0x5e));
++  compositor.Composite(Color.FromArgb(0xa0, 0x18, 0xa0, 0x5e));

那么可以设置为全透明吗？

    var compositor = new WindowAccentCompositor(this);
--  compositor.Composite(Color.FromRgb(0x18, 0xa0, 0x5e));
++  compositor.Composite(Color.FromArgb(0x00, 0x18, 0xa0, 0x5e));

很不幸，最终你会完全看不到亚克力效果，而变成了毫无特效的透明窗口：

最上面那根白线，是我面前面设置边框为 0 1 0 0 导致的。

如果在这种情况下，将边框设置为 0 会怎样呢？记得前面我们说过的吗，会导致阴影消失哦！

呃……你将看到……这个……

什么都没有……

是不是找到了一条新的背景透明异形窗口的方法？

还是省点心吧，亚克力效果在 Win32 应用上的性能还是比较堪忧的……

想要背景透明，请参见：

• WPF 制作高性能的透明背景异形窗口（使用 WindowChrome 而不要使用 AllowsTransparency=True） - walterlv

不用考虑 Windows 7，因为大家都知道不支持。实际效果会跟前面的一模一样。

AccentState=ACCENT_INVALID_STATE

这个值其实不用说了，因为 AccentState 在不同系统中可用的值不同，为了保证向后兼容性，对于新系统中设置的值，旧系统其实就视之为 ACCENT_INVALID_STATE。

那么如果系统认为设置的是 ACCENT_INVALID_STATE 会显示成什么样子呢？

答案是，与 ACCENT_DISABLED 完全相同。

总结

由于 Windows 7 上所有的值都是同样的效果，所以下表仅适用于 Windows 10。

在以上的特效之下，WindowChrome 可以让客户区覆盖非客户区，或者让整个窗口都获得特效，而不只是标题栏。

附源代码

请参见 GitHub 地址以获得最新代码。如果不方便访问，那么就看下面的吧。

• Walterlv.Packages/WindowAccentCompositor.cs at master · walterlv/Walterlv.Packages

using System;
using System.Runtime.InteropServices;
using System.Windows;
using System.Windows.Interop;
using System.Windows.Media;

namespace Walterlv.Windows.Effects
{
    /// <summary>
    /// 为窗口提供模糊特效。
    /// </summary>
    public class WindowAccentCompositor
    {
        private readonly Window _window;

        /// <summary>
        /// 创建 <see cref="WindowAccentCompositor"/> 的一个新实例。
        /// </summary>
        /// <param name="window">要创建模糊特效的窗口实例。</param>
        public WindowAccentCompositor(Window window) => _window = window ?? throw new ArgumentNullException(nameof(window));

        public void Composite(Color color)
        {
            Window window = _window;
            var handle = new WindowInteropHelper(window).EnsureHandle();

            var gradientColor =
                // 组装红色分量。
                color.R << 0 |
                // 组装绿色分量。
                color.G << 8 |
                // 组装蓝色分量。
                color.B << 16 |
                // 组装透明分量。
                color.A << 24;

            Composite(handle, gradientColor);
        }

        private void Composite(IntPtr handle, int color)
        {
            // 创建 AccentPolicy 对象。
            var accent = new AccentPolicy
            {
                AccentState = AccentState.ACCENT_ENABLE_ACRYLICBLURBEHIND,
                GradientColor = 0,
            };

            // 将托管结构转换为非托管对象。
            var accentPolicySize = Marshal.SizeOf(accent);
            var accentPtr = Marshal.AllocHGlobal(accentPolicySize);
            Marshal.StructureToPtr(accent, accentPtr, false);

            // 设置窗口组合特性。
            try
            {
                // 设置模糊特效。
                var data = new WindowCompositionAttributeData
                {
                    Attribute = WindowCompositionAttribute.WCA_ACCENT_POLICY,
                    SizeOfData = accentPolicySize,
                    Data = accentPtr,
                };
                SetWindowCompositionAttribute(handle, ref data);
            }
            finally
            {
                // 释放非托管对象。
                Marshal.FreeHGlobal(accentPtr);
            }
        }

        [DllImport("user32.dll")]
        private static extern int SetWindowCompositionAttribute(IntPtr hwnd, ref WindowCompositionAttributeData data);

        private enum AccentState
        {
            ACCENT_DISABLED = 0,
            ACCENT_ENABLE_GRADIENT = 1,
            ACCENT_ENABLE_TRANSPARENTGRADIENT = 2,
            ACCENT_ENABLE_BLURBEHIND = 3,
            ACCENT_ENABLE_ACRYLICBLURBEHIND = 4,
            ACCENT_INVALID_STATE = 5,
        }

        [StructLayout(LayoutKind.Sequential)]
        private struct AccentPolicy
        {
            public AccentState AccentState;
            public int AccentFlags;
            public int GradientColor;
            public int AnimationId;
        }

        [StructLayout(LayoutKind.Sequential)]
        private struct WindowCompositionAttributeData
        {
            public WindowCompositionAttribute Attribute;
            public IntPtr Data;
            public int SizeOfData;
        }

        private enum WindowCompositionAttribute
        {
            // 省略其他未使用的字段
            WCA_ACCENT_POLICY = 19,
            // 省略其他未使用的字段
        }
    }
}

WPF 程序如何移动焦点到其他控件

WPF 中可以使用 UIElement.Focus() 将焦点设置到某个特定的控件，也可以使用 TraversalRequest 仅仅移动焦点。本文介绍如何在 WPF 程序中控制控件的焦点。

UIElement.Focus

仅仅需要在任何一个控件上调用 Focus() 方法即可将焦点设置到这个控件上。

但是需要注意，要使 Focus() 能够工作，这个元素必须满足两个条件：

• Focusable 设置为 true
• IsVisible 是 true

TraversalRequest

如果你并不是将焦点设置到某个特定的控件，而是希望将焦点转移，可以考虑使用 TraversalRequest 类。

比如，以下代码是将焦点转移到下一个控件，也就是按下 Tab 键时焦点会去的控件。

var traversalRequest = new TraversalRequest(FocusNavigationDirection.Next);
// view 是可视化树中的一个控件。
view.MoveFocus(traversalRequest);

关于逻辑焦点和键盘焦点

键盘焦点就是你实际上按键输入和快捷键会生效的焦点，也就是当前正在工作的控件的焦点。

而 WPF 有多个焦点范围（Focus Scope），按下 Tab 键切换焦点的时候只会在当前焦点范围切焦点，不会跨范围。那么一旦跨范围切焦点的时候，焦点会去哪里呢？答案是逻辑焦点。

每个焦点范围内都有一个逻辑焦点，记录如果这个焦点范围一旦获得焦点后应该在哪个控件获得键盘焦点。

比如默认情况下 WPF 每个 Window 就是一个焦点范围，那么每个 Window 中的当前焦点就是逻辑焦点。而一旦这个 Window 激活，那么这个窗口中的逻辑焦点就会成为键盘焦点，另一个窗口当中的逻辑焦点保留，而键盘焦点则丢失。

跨窗口/跨进程切换焦点

参见我的另一篇博客：

• WPF 程序如何跨窗口/跨进程设置控件焦点

参考资料

• winapi - Win32: C++: How do I re-focus on Parent Window after clicking in a child window? - Stack Overflow

使用 SetParent 制作父子窗口的时候，如何设置子窗口的窗口样式以避免抢走父窗口的焦点

制作传统 Win32 程序以及 Windows Forms 程序的时候，一个用户看起来独立的窗口本就是通过各种父子窗口嵌套完成的，有大量窗口句柄，窗口之间形成父子关系。不过，对于 WPF 程序来说，一个独立的窗口实际上只有一个窗口句柄，窗口内的所有内容都是 WPF 绘制的。

如果你不熟悉 Win32 窗口中的父子窗口关系和窗口样式，那么很有可能遇到父子窗口之间“抢夺焦点”的问题，本文介绍如何解决这样的问题。

“抢夺焦点”

下图中的上下两个部分是两个不同的窗口，他们之间通过 SetParent 建立了父子关系。

注意看下面的窗口标题栏，当我在这些不同区域间点击的时候，窗口标题栏在黑色和灰色之间切换：

这说明当子窗口获得焦点的时候，父窗口会失去焦点并显示失去焦点的样式。

你可以在这篇博客中找到一个简单的例子：

解决办法

而原因和解决方法仅有一个，就是子窗口需要有一个子窗口的样式。

具体来说，子窗口必须要有 WS_CHILD 样式。

你可以看看 Spyxx.exe 抓出来的默认普通窗口和子窗口的样式差别：

![默认普通窗口]](/static/posts/2019-09-19-10-21-31.png)

▲ 默认普通窗口

▲ 子窗口

参考资料

• 关于WS_CLIPCHILDREN和WS_CLIPSIBLINGS的理解（个人认为还是相当全面的） - helloj2ee - 博客园

如何在 WPF 中获取所有已经显式赋过值的依赖项属性

获取 WPF 的依赖项属性的值时，会依照优先级去各个级别获取。这样，无论你什么时候去获取依赖项属性，都至少是有一个有效值的。有什么方法可以获取哪些属性被显式赋值过呢？如果是 CLR 属性，我们可以自己写判断条件，然而依赖项属性没有自己写判断条件的地方。

本文介绍如何获取以及显式赋值过的依赖项属性。

需要用到 DependencyObject.GetLocalValueEnumerator() 方法来获得一个可以遍历所有依赖项属性本地值。

public static void DoWhatYouLikeByWalterlv(DependencyObject dependencyObject)
{
    var enumerator = dependencyObject.GetLocalValueEnumerator();
    while (enumerator.MoveNext())
    {
        var entry = enumerator.Current;
        var property = entry.Property;
        var value = entry.Value;
        // 在这里使用 property 和 value。
    }
}

这里的 value 可能是 MarkupExtension 可能是 BindingExpression 还可能是其他一些可能延迟计算值的提供者。因此，你不能在这里获取到常规方法获取到的依赖项属性的真实类型的值。

但是，此枚举拿到的所有依赖项属性的值都是此依赖对象已经赋值过的依赖项属性的本地值。如果没有赋值过，将不会在这里的遍历中出现。

参考资料

• Dependency properties overview - Microsoft Docs

在 WPF 中获取一个依赖对象的所有依赖项属性

本文介绍如何在 WPF 中获取一个依赖对象的所有依赖项属性。

通过 WPF 标记获取

public static IEnumerable<DependencyProperty> EnumerateDependencyProperties(object element)
{
    if (element is null)
    {
        throw new ArgumentNullException(nameof(element));
    }

    MarkupObject markupObject = MarkupWriter.GetMarkupObjectFor(element);
    if (markupObject != null)
    {
        foreach (MarkupProperty mp in markupObject.Properties)
        {
            if (mp.DependencyProperty != null)
            {
                yield return mp.DependencyProperty;
            }
        }
    }
}

public static IEnumerable<DependencyProperty> EnumerateAttachedProperties(object element)
{
    if (element is null)
    {
        throw new ArgumentNullException(nameof(element));
    }

    MarkupObject markupObject = MarkupWriter.GetMarkupObjectFor(element);
    if (markupObject != null)
    {
        foreach (MarkupProperty mp in markupObject.Properties)
        {
            if (mp.IsAttached)
            {
                yield return mp.DependencyProperty;
            }
        }
    }
}

通过设计器专用方法获取

本来 .NET 中提供了一些专供设计器使用的类型 TypeDescriptor 可以帮助设计器找到一个类型或者组件的所有可以设置的属性，不过我们也可以通过此方法来获取所有可供使用的属性。

下面是带有重载的两个方法，一个传入类型一个传入实例。

/// <summary>
/// 获取一个对象中所有的依赖项属性。
/// </summary>
public static IEnumerable<DependencyProperty> GetDependencyProperties(object instance)
    => TypeDescriptor.GetProperties(instance, new Attribute[] { new PropertyFilterAttribute(PropertyFilterOptions.All) })
        .OfType<PropertyDescriptor>()
        .Select(x => DependencyPropertyDescriptor.FromProperty(x)?.DependencyProperty)
        .Where(x => x != null);

/// <summary>
/// 获取一个类型中所有的依赖项属性。
/// </summary>
public static IEnumerable<DependencyProperty> GetDependencyProperties(Type type)
    => TypeDescriptor.GetProperties(type, new Attribute[] { new PropertyFilterAttribute(PropertyFilterOptions.All) })
        .OfType<PropertyDescriptor>()
        .Select(x => DependencyPropertyDescriptor.FromProperty(x)?.DependencyProperty)
        .Where(x => x != null);

参考资料

• wpf - How to enumerate all dependency properties of control? - Stack Overflow
• Getting list of all dependency/attached properties of an Object

WPF 不要给 Window 类设置变换矩阵（分析篇）：System.InvalidOperationException: 转换不可逆。

最近总是收到一个异常 “System.InvalidOperationException: 转换不可逆。”，然而看其堆栈，一点点自己写的代码都没有。到底哪里除了问题呢？

虽然异常堆栈信息里面没有自己编写的代码，但是我们还是找到了问题的原因和解决方法。

异常堆栈

这就是抓到的此问题的异常堆栈：

System.InvalidOperationException: 转换不可逆。
   在 System.Windows.Media.Matrix.Invert()
   在 MS.Internal.PointUtil.TryApplyVisualTransform(Point point, Visual v, Boolean inverse, Boolean throwOnError, Boolean& success)
   在 MS.Internal.PointUtil.TryClientToRoot(Point point, PresentationSource presentationSource, Boolean throwOnError, Boolean& success)
   在 System.Windows.Input.MouseDevice.LocalHitTest(Boolean clientUnits, Point pt, PresentationSource inputSource, IInputElement& enabledHit, IInputElement& originalHit)
   在 System.Windows.Input.MouseDevice.GlobalHitTest(Boolean clientUnits, Point pt, PresentationSource inputSource, IInputElement& enabledHit, IInputElement& originalHit)
   在 System.Windows.Input.StylusWisp.WispStylusDevice.FindTarget(PresentationSource inputSource, Point position)
   在 System.Windows.Input.StylusWisp.WispLogic.PreNotifyInput(Object sender, NotifyInputEventArgs e)
   在 System.Windows.Input.InputManager.ProcessStagingArea()
   在 System.Windows.Input.InputManager.ProcessInput(InputEventArgs input)
   在 System.Windows.Input.StylusWisp.WispLogic.InputManagerProcessInput(Object oInput)
   在 System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   在 System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

可以看到，我们的堆栈结束点是 ExceptionWrapper.TryCatchWhen 可以得知此异常是通过 Dispatcher.UnhandledException 来捕获的。也就是说，此异常直接通过 Windows 消息被我们间接触发，而不是直接通过我们编写的代码触发。而最顶端是对矩阵求逆，而此异常是试图对一个不可逆的矩阵求逆。

分析过程

如果你不想看分析过程，可以直接移步至本文的最后一节看原因和解决方案。

源代码

因为 .NET Framework 版本的 WPF 是开源的，.NET Core 版本的 WPF 目前还处于按揭开源的状态，所以我们看 .NET Framework 版本的代码来分析原因。

我按照调用堆栈从顶到底的顺序，将前面三帧的代码贴到下面。

PointUtil.TryApplyVisualTransform

public static Point TryApplyVisualTransform(Point point, Visual v, bool inverse, bool throwOnError, out bool success)
{
    success = true;

    if(v != null)
    {
        Matrix m = GetVisualTransform(v);

        if (inverse)
        {
            if(throwOnError || m.HasInverse)
            {
                m.Invert();
            }
            else
            {
                success = false;
                return new Point(0,0);
            }
        }

        point = m.Transform(point);
    }

    return point;
}

PointUtil.TryClientToRoot

[SecurityCritical,SecurityTreatAsSafe]
public static Point TryClientToRoot(Point point, PresentationSource presentationSource, bool throwOnError, out bool success)
{
    if (throwOnError || (presentationSource != null && presentationSource.CompositionTarget != null && !presentationSource.CompositionTarget.IsDisposed))
    {
        point = presentationSource.CompositionTarget.TransformFromDevice.Transform(point);
        point = TryApplyVisualTransform(point, presentationSource.RootVisual, true, throwOnError, out success);
    }
    else
    {
        success = false;
        return new Point(0,0);
    }

    return point;
}

你可能会说，在调用堆栈上面看不到 PointUtil.ClientToRoot 方法。但其实如果我们看一看 MouseDevice.LocalHitTest 的代码，会发现其实调用的是 PointUtil.ClientToRoot 方法。在调用堆栈上面看不到它是因为方法足够简单，被内联了。

[SecurityCritical,SecurityTreatAsSafe]
public static Point ClientToRoot(Point point, PresentationSource presentationSource)
{
    bool success = true;
    return TryClientToRoot(point, presentationSource, true, out success);
}

求逆的矩阵

下面我们一步一步分析异常的原因。

我们先看看是什么代码在做矩阵求逆。下面截图中的方法是反编译的，就是上面我们在源代码中列出的 TryApplyVisualTransform 方法。

先获取了传入 Visual 对象的变换矩阵，然后根据参数 inverse 来对其求逆。如果矩阵可以求逆，即 HasInverse 属性返回 true，那么代码可以继续执行下去而不会出现异常。但如果 HasInverse 返回 false，则根据 throwOnError 来决定是否抛出异常，在需要抛出异常的情况下会真实求逆，也就是上面截图中我们看到的异常发生处的代码。

那么接下来我们需要验证三点：

1. 这个 Visual 是哪里来的；
2. 这个 Visual 的变换矩阵什么情况下不可求逆；
3. throwOnError 确定传入的是 true 吗。

于是我们继续往上层调用代码中查看。

可以很快验证上面需要验证的两个点：

1. throwOnError 传入的是 true；
2. Visual 是 PresentationSource 的 RootVisual。

而 PresentationSource 的 RootVisual 是什么呢？PresentationSource 是承载 WPF 可视化树的一个对象，对于窗口 Window，是通过 HwndSource（PresentationSource 的子类）承载的；对于跨线程 WPF UI，可以通过自定义的 PresentationSource 子类来完成。这部分可以参考我之前的一些博客：

• WPF 同一窗口内的多线程 UI（VisualTarget）
• WPF 同一窗口内的多线程/多进程 UI（使用 SetParent 嵌入另一个窗口）
• WPF 多线程 UI：设计一个异步加载 UI 的容器
• WPF 获取元素（Visual）相对于屏幕设备的缩放比例，可用于清晰显示图片

不管怎么说，这个指的就是 WPF 可视化树的根：

• 如果你使用 Window 来显示 WPF 窗口，那么根就是 Window 类；
• 如果你是用 Popup 来承载一个弹出框，那么根就是 PopupRoot 类；
• 如果你使用了一些跨线程/跨进程 UI 的技术，那么根就是自己写的可视化树根元素。

对于绝大多数 WPF 开发者来说，只会碰到前面第一种情况，也就是仅仅有 Window 作为可视化树的根的情况。一般人很难直接给 PopupRoot 设置变换矩阵，一般 WPF 程序的代码也很少做跨线程或跨进程 UI。

于是我们几乎可以肯定，是有某处的代码让 Window 的变换矩阵不可逆了。

矩阵求逆

什么样的矩阵是不可逆的？

异常代码

发生异常的代码是 WPF 中 Matrix.Invert 方法，其发生异常的代码如下：

首先判断矩阵的行列式 Determinant 是否为 0，如果为 0 则抛出矩阵不可逆的异常。

行列式

WPF 的 2D 变换矩阵 \(M\) 是一个 \(3\times{3}\) 的矩阵：

其行列式 \(det(M)\) 是一个标量：

因为矩阵求逆的时候，行列式的值会作为分母，于是会无法计算，所以行列式的值为 0 时，矩阵不可逆。

前面我们计算 WPF 的 2D 变换矩阵的行列式的值为 \(M11 \times M22 - M12 \times M21\)，因此，只要使这个式子的值为 0 即可。

那么 WPF 的 2D 变换的时候，如何使此值为 0 呢？

• 平移？平移只会修改 \(OffsetX\) 和 \(OffsetY\)，因此对结果没有影响
• 缩放？缩放会将原矩阵点乘缩放矩阵
• 旋转？旋转会将旋转矩阵点乘原矩阵

其中，原矩阵在我们的场景下就是恒等的矩阵，即 Matrix.Identity：

接下来缩放和旋转我们都不考虑变换中心的问题，因为变换中心的问题都可以等价为先进行缩放和旋转后，再单纯进行平移。由于平移对行列式的值没有影响，于是我们忽略。

缩放矩阵

缩放矩阵。如果水平和垂直分量分别缩放 \(ScaleX\) 和 \(ScaleY\) 倍，则缩放矩阵为：

原矩阵点乘缩放矩阵结果为：

于是，只要 \(ScaleX\) 和 \(ScaleY\) 任何一个为 0 就可以导致新矩阵的行列式必定为 0。

旋转矩阵

旋转矩阵。假设用户设置的旋转角度为 angle，那么换算成弧度为 angle * (Math.PI/180.0)，我们将弧度记为 \(\alpha\)，那么旋转矩阵为：

旋转矩阵点乘原矩阵的结果为：

对此矩阵的行列式求值：

也就是说其行列式的值恒等于 1，因此其矩阵必然可求逆。

WPF 2D 变换矩阵求逆小结

对于 WPF 的 2D 变换矩阵：

1. 平移和旋转不可能导致矩阵不可逆；
2. 缩放，只要水平和垂直方向的任何一个分量缩放量为 0，矩阵就会不可逆。

寻找问题代码

现在，我们寻找问题的方向已经非常明确了：

• 找到设置了 ScaleTransform 的 Window，检查其是否给 ScaleX 或者 ScaleY 属性赋值为了 0。

然而，真正写一个 demo 程序来验证这个问题的时候，就发现没有这么简单。因为：

我们发现，不止是 ScaleX 和 ScaleY 属性不能设为 0，实际上设成 0.5 或者其他值也是不行的。

唯一合理值是 1。

那么为什么依然有异常呢？难道是 ScaleTransform 的值一开始正常，然后被修改？

编写 demo 验证，果然如此。而只有变换到 0 才会真的引发本文一开始我们提到的异常。一般会开始设为 1 而后设为 0 的代码通常是在做动画。

一定是有代码正在为窗口的 ScaleTransform 做动画。

结果全代码仓库搜索 ScaleTransform 真的找到了问题代码。

<Window x:Name="WalterlvDoubiWindow"
        x:Class="Walterlv.Exceptions.Unknown.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        mc:Ignorable="d"
        Title="MainWindow" Height="450" Width="800">
    <Window.RenderTransform>
        <ScaleTransform ScaleX="1" ScaleY="1" />
    </Window.RenderTransform>
    <Window.Resources>
        <Storyboard x:Key="Storyboard.Load">
            <DoubleAnimation Storyboard.TargetName="WalterlvDoubiWindow"
                             Storyboard.TargetProperty="(UIElement.RenderTransform).(ScaleTransform.ScaleX)"
                             From="0" To="1" />
            <DoubleAnimation Storyboard.TargetName="WalterlvDoubiWindow"
                             Storyboard.TargetProperty="(UIElement.RenderTransform).(ScaleTransform.ScaleY)"
                             From="0" To="1" />
        </Storyboard>
    </Window.Resources>
    <Grid>
        <!-- 省略的代码 -->
    </Grid>
</Window>

不过，这段代码并不会导致每次都出现异常，而是在非常多次尝试中偶尔能出现一次异常。

原因和解决方案

原因

1. Window 类是不可以设置 RenderTransform 属性的，但允许设置恒等（Matrix.Identity）的变换；
2. 如果让 Window 类缩放分量设置为 0，就会出现矩阵不可逆异常。

解决方案

不要给 Window 类设置变换，如果要做，请给 Window 内部的子元素设置。比如上面的例子中，我们给 Grid 设置就没有问题（而且可以做到类似的效果。

WPF 不要给 Window 类设置变换矩阵（应用篇）

WPF 的 Window 类是不允许设置变换矩阵的。不过，总会有小伙伴为了能够设置一下试图绕过一些验证机制。

不要试图绕过，因为你会遇到更多问题。

试图设置变换矩阵

当你试图给 Window 类设置变换矩阵的时候，会出现异常：

System.InvalidOperationException:“转换对于 Window 无效。”

无论是缩放还是旋转，都一样会出现异常。

我们在 WPF 不要给 Window 类设置变换矩阵（分析篇） 一文中已经证明在 WPF 的 2D 变换中，旋转一定不会造成矩阵不可逆，因此此验证是针对此属性的强验证。

只有做设置的变换是恒等变换的时候，才可以完成设置。

this.RenderTransform = new TranslateTransform(0, 0);
this.RenderTransform = new ScaleTransform(1, 1);
this.RenderTransform = new RotateTransform(0);
this.RenderTransform = new MatrixTransform(Matrix.Identity);

绕过验证

然而你可以通过先设置变换，再修改变换值的方式绕过验证：

var scaleTransform = new ScaleTransform(1, 1);
this.RenderTransform = scaleTransform;
scaleTransform.ScaleX = 0.5;
scaleTransform.ScaleY = 0.5;

实际上，你绕过也没有关系，可是这样的设置实际上是没有任何效果的。

不过为什么还是会有小伙伴这么设置呢？

是因为小伙伴同时还设置了窗口透明 AllowsTransparency="True"、WindowStyle="None" 和 Background="Transparent"，导致看起来好像这个变换生效了一样。

小心异常

此设置不仅没有效果，还会引发异常，请阅读我的另一篇博客了解：

• WPF 不要给 Window 类设置变换矩阵（分析篇）：System.InvalidOperationException: 转换不可逆。

WPF 的 Application.Current.Dispatcher 中，为什么 Current 可能为 null

在 WPF 程序中，可能会存在 Application.Current.Dispatcher.Xxx 这样的代码让一部分逻辑回到主 UI 线程。因为发现在调用这句代码的时候出现了 NullReferenceException，于是就有三位小伙伴告诉我说 Current 和 Dispatcher 属性都可能为 null。

然而实际上这里只可能 Current 为 null 而此上下文的 Dispatcher 是绝对不会为 null 的。（当然我们这里讨论的是常规编程手段，如果非常规手段，你甚至可以让实例的 this 为 null 呢……）

当你的应用程序退出时，所有 UI 线程的代码都不再会执行，因此这是安全的；但所有非 UI 线程的代码依然在继续执行，此时随时可能遇到 Application.Current 属性为 null。

由于本文所述的两个部分都略长，所以拆分成两篇博客，这样更容易理解。

• WPF 的 Application.Current.Dispatcher 中，Dispatcher 属性一定不会为 null
• WPF 的 Application.Current.Dispatcher 中，为什么 Current 可能为 null

Application.Current 静态属性

源代码

Application 类型的源代码会非常长，所以这里就不贴了，可以前往这里查看：

• DispatcherObject.cs

其中，Current 返回的是 _appInstance 的静态字段。因此 _appInstance 字段为 null 的时机就是 Application.Current 为 null 的时机。

/// <summary>
///     The Current property enables the developer to always get to the application in
///     AppDomain in which they are running.
/// </summary>
static public Application Current
{
    get
    {
        // There is no need to take the _globalLock because reading a
        // reference is an atomic operation. Moreover taking a lock
        // also causes risk of re-entrancy because it pumps messages.

        return _appInstance;
    }
}

由于 _appInstance 字段是私有字段，所以仅需调查这个类本身即可找到所有的赋值时机。（反射等非常规手段需要排除在外，因为这意味着开发者是逗比——自己闯的祸不能怪 WPF 框架。）

赋值时机

_appInstance 的赋值时机有两处：

1. Application 的实例构造函数（注意哦，是实例构造函数而不是静态构造函数）；
2. Application.DoShutdown 方法。

在 Application 的实例构造函数中：

• _appInstance 的赋值是线程安全的，这意味着多个 Application 实例的构造不会因为线程安全问题导致 _appInstance 字段的状态不正确。
• 如果 _appCreatedInThisAppDomain 为 true 那么，将抛出异常，组织此应用程序域中创建第二个 Application 类型的实例。

/// <summary>
///     Application constructor
/// </summary>
/// <SecurityNote>
///    Critical: This code posts a work item to start dispatcher if in the browser
///    PublicOk: It is ok because the call itself is not exposed and the application object does this internally.
/// </SecurityNote>
[SecurityCritical]
public Application()
{
    // 省略了一部分代码。
    lock(_globalLock)
    {
        // set the default statics
        // DO NOT move this from the begining of this constructor
        if (_appCreatedInThisAppDomain == false)
        {
            Debug.Assert(_appInstance == null, "_appInstance must be null here.");
            _appInstance = this;
            IsShuttingDown    = false;
            _appCreatedInThisAppDomain = true;
        }
        else
        {
            //lock will be released, so no worries about throwing an exception inside the lock
            throw new InvalidOperationException(SR.Get(SRID.MultiSingleton));
        }
    }
    // 省略了一部分代码。
}

也就是说，此类型实际上是设计为单例的。在第一个实例构造出来之后，单例的实例即可开始使用。

后续赋值

此单例实例的唯一结束时机就是 Application.DoShutdown 方法。这是唯一将 _appInstance 赋值为 null 的代码。

/// <summary>
/// DO NOT USE - internal method
/// </summary>
///<SecurityNote>
///     Critical: Calls critical code: Window.InternalClose
///     Critical: Calls critical code: HwndSource.Dispose
///     Critical: Calls critical code: PreloadedPackages.Clear()
///</SecurityNote>
[SecurityCritical]
internal virtual void DoShutdown()
{
    // 省略了一部分代码。

    // Event handler exception continuality: if exception occurs in ShuttingDown event handler,
    // our cleanup action is to finish Shuttingdown.  Since Shuttingdown cannot be cancelled.
    // We don't want user to use throw exception and catch it to cancel Shuttingdown.
    try
    {
        // fire Applicaiton Exit event
        OnExit(e);
    }
    finally
    {
        SetExitCode(e._exitCode);

        // By default statics are shared across appdomains, so need to clear
        lock (_globalLock)
        {
            _appInstance = null;
        }

        _mainWindow = null;
        _htProps = null;
        NonAppWindowsInternal = null;

        // 省略了一部分代码。
    }
}

可以调用到此代码的公共 API 有：

• Application.Shutdown 实例方法
• 导致 Window 关闭的若干方法（InternalDispose）
• IBrowserHostServices.PostShutdown 接口方法

因此，所有直接或间接调用到以上方法的地方都会导致 Application.Current 属性被赋值为 null。

对所写代码的影响

从以上的分析可以得知，只要你还能在 Application.DoShutdown 执行之后继续执行代码，那么这部分的代码都将面临着 Application.Current 为 null 风险。

那么，到底有哪些时机可能遇到 Application.Current 为 null 呢？这部分就与读者项目中所用的业务代码强相关了。

但是这部分业务代码会有一些公共特征帮助你判定你是否可能写出遭遇 Application.Current 为 null 的代码。

此特征是：此代码与 Application.Current 不在同一线程。

与 Application.Current 不在同一线程

对于 WPF 程序，你的多数代码可能是由用户交互产生，即便有后续代码的执行，也依然是从 UI 交互产生。这样的代码不会遇到 Application.Current 为 null 的情况。

但是，如果你的代码由非 UI 线程触发，例如在 Usb 设备改变、与其他端的通信、某些异步代码的回调等等，这些代码不受 Dispatcher 是否调度影响，几乎一定会执行。因此 Application.Current 就算赋值为 null 了，它们也不知道，依然会继续执行，于是就会遭遇 Application.Current 为 null。

这本质上是一个线程安全问题。

使用 Invoke/BeginInvoke/InvokeAsync 的代码不会出问题

Application.DoShutdown 方法被 ShutdownImpl 包装，且所有调用均从此包装进入，因此，所有可能导致 Application.Current 为 null 的代码，均会调用此方法，也就是说，会调用 Dispatcher.CriticalInvokeShutdown 实例方法。

/// <summary>
/// This method gets called on dispatch of the Shutdown DispatcherOperationCallback
/// </summary>
///<SecurityNote>
///  Critical: Calls critical code: DoShutdown, Dispatcher.CritcalInvokeShutdown()
///</SecurityNote>
[SecurityCritical]
private void ShutdownImpl()
{
    // Event handler exception continuality: if exception occurs in Exit event handler,
    // our cleanup action is to finish Shutdown since Exit cannot be cancelled. We don't
    // want user to use throw exception and catch it to cancel Shutdown.
    try
    {
        DoShutdown();
    }
    finally
    {
        // Quit the dispatcher if we ran our own.
        if (_ownDispatcherStarted == true)
        {
            Dispatcher.CriticalInvokeShutdown();
        }

        ServiceProvider = null;
    }
}

所有的关闭 Dispatcher 的调用有两类，Application 关闭时调用的是内部方法 CriticalInvokeShutdown。

1. 立即关闭 CriticalInvokeShutdown，即以 Send 优先级 Invoke 关闭方法，而 Send 优先级调用 Invoke 几乎等同于直接调用（为什么是等同而不是直接调用？因为还需要考虑回到 Dispatcher 初始化时所在的线程）。
2. 开始关闭 BeginInvokeShutdown，即以指定的优先级 InvokeAsync 关闭方法。

而关闭 Dispatcher 意味着所有使用 Invoke/BeginInvoke/InvokeAsync 的任务将终止。

//<SecurityNote>
//  Critical - as it accesses security critical data ( window handle)
//</SecurityNote>
[SecurityCritical]
private void ShutdownImplInSecurityContext(Object state)
{
    // 省略了一部分代码。

    // Now that the queue is off-line, abort all pending operations,
    // including inactive ones.
    DispatcherOperation operation = null;
    do
    {
        lock(_instanceLock)
        {
            if(_queue.MaxPriority != DispatcherPriority.Invalid)
            {
                operation = _queue.Peek();
            }
            else
            {
                operation = null;
            }
        }

        if(operation != null)
        {
            operation.Abort();
        }
    } while(operation != null);

    // 省略了一部分代码。
}

由于此终止代码在 Dispatcher 所在的线程执行，而所有 Invoke/BeginInvoke/InvokeAsync 代码也都在此线程执行，因此这些代码均不会并发。已经执行的代码会在此终止代码之前，而在此终止代码之后也不会再执行任何 Invoke/BeginInvoke/InvokeAsync 的任务了。

• 所有通过 Invoke/BeginInvoke/InvokeAsync 或间接通过此方法（如 WPF 控件相关事件）调用的代码，均不会遭遇 Application.Current 为 null。
• 所有在 UI 线程使用 async / await 并使用默认上下文执行的代码，均不会遭遇 Application.Current 为 null。（这意味着你没有使用 .ConfigureAwait(false)，详见在编写异步方法时，使用 ConfigureAwait(false) 避免使用者死锁 - walterlv。）

最简示例代码

using System;
using System.Threading;
using System.Threading.Tasks;
using System.Windows;

namespace Walterlv.Demo.ApplicationDispatcher
{
    class Program
    {
        [STAThread]
        static void Main(string[] args)
        {
            var app = new Application();
            Task.Delay(1000).ContinueWith(t =>
            {
                app.Dispatcher.InvokeAsync(() => app.Shutdown());
            });
            Task.Delay(2000).ContinueWith(t =>
            {
                Application.Current.Dispatcher.InvokeAsync(() => { });
            });
            app.Run();
            Thread.Sleep(2000);
        }
    }
}

结论

总结以上所有的分析：

1. 任何与 Application 不在同一个线程的代码，都可能遭遇 Application.Current 为 null。
2. 任何与 Application 在同一个线程的代码，都不可能遇到 Application.Current 为 null。

这其实是一个线程安全问题。用所有业务开发者都可以理解的说法描述就是：

当你的应用程序退出时，所有 UI 线程的代码都不再会执行，因此这是安全的；但所有非 UI 线程的代码依然在继续执行，此时随时可能遇到 Application.Current 属性为 null。

因此，记得所有非 UI 线程的代码，如果需要转移到 UI 线程执行，记得判空：

private void OnUsbDeviceChanged(object sender, EventArgs e)
{
    // 记得这里需要判空，因为此上下文可能在非 UI 线程。
    Application.Current?.InvokeAsync(() => { });
}

Application.Dispatcher 实例属性

关于 Application.Dispatcher 是否可能为 null 的分析，由于比较长，请参见我的另一篇博客：

• WPF 的 Application.Current.Dispatcher 中，Dispatcher 属性一定不会为 null - walterlv

参考资料

• Application.cs

WPF 的 Application.Current.Dispatcher 中，Dispatcher 属性一定不会为 null

在 WPF 程序中，可能会存在 Application.Current.Dispatcher.Xxx 这样的代码让一部分逻辑回到主 UI 线程。因为发现在调用这句代码的时候出现了 NullReferenceException，于是就有三位小伙伴告诉我说 Current 和 Dispatcher 属性都可能为 null。

然而实际上这里只可能 Current 为 null 而此上下文的 Dispatcher 是绝对不会为 null 的。（当然我们这里讨论的是常规编程手段，如果非常规手段，你甚至可以让实例的 this 为 null 呢……）

由于本文所述的两个部分都略长，所以拆分成两篇博客，这样更容易理解。

• WPF 的 Application.Current.Dispatcher 中，Dispatcher 属性一定不会为 null
• WPF 的 Application.Current.Dispatcher 中，为什么 Current 可能为 null

Application.Dispatcher 实例属性

Application.Dispatcher 实例属性来自于 DispatcherObject。

源代码

为了分析此属性是否可能为 null，我现在将 DispatcherObject 的全部代码贴在下面：

using System;
using System.Windows;
using System.Threading;
using MS.Internal.WindowsBase;               // FriendAccessAllowed
 
namespace System.Windows.Threading
{
    /// <summary>
    ///     A DispatcherObject is an object associated with a
    ///     <see cref="Dispatcher"/>.  A DispatcherObject instance should
    ///     only be access by the dispatcher's thread.
    /// </summary>
    /// <remarks>
    ///     Subclasses of <see cref="DispatcherObject"/> should enforce thread
    ///     safety by calling <see cref="VerifyAccess"/> on all their public
    ///     methods to ensure the calling thread is the appropriate thread.
    ///     <para/>
    ///     DispatcherObject cannot be independently instantiated; that is,
    ///     all constructors are protected.
    /// </remarks>
    public abstract class DispatcherObject
    {
        /// <summary>
        ///     Returns the <see cref="Dispatcher"/> that this
        ///     <see cref="DispatcherObject"/> is associated with.
        /// </summary>
        [System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Advanced)]
        public Dispatcher Dispatcher
        {
            get
            {
                // This property is free-threaded.
 
                return _dispatcher;
            }
        }
 
        // This method allows certain derived classes to break the dispatcher affinity
        // of our objects.
        [FriendAccessAllowed] // Built into Base, also used by Framework.
        internal void DetachFromDispatcher()
        {
            _dispatcher = null;
        }
 
        // Make this object a "sentinel" - it can be used in equality tests, but should
        // not be used in any other way.  To enforce this and catch bugs, use a special
        // sentinel dispatcher, so that calls to CheckAccess and VerifyAccess will
        // fail;  this will catch most accidental uses of the sentinel.
        [FriendAccessAllowed] // Built into Base, also used by Framework.
        internal void MakeSentinel()
        {
            _dispatcher = EnsureSentinelDispatcher();
        }
 
        private static Dispatcher EnsureSentinelDispatcher()
        {
            if (_sentinelDispatcher == null)
            {
                // lazy creation - the first thread reaching here creates the sentinel
                // dispatcher, all other threads use it.
                Dispatcher sentinelDispatcher = new Dispatcher(isSentinel:true);
                Interlocked.CompareExchange<Dispatcher>(ref _sentinelDispatcher, sentinelDispatcher, null);
            }
 
            return _sentinelDispatcher;
        }
 
        /// <summary>
        ///     Checks that the calling thread has access to this object.
        /// </summary>
        /// <remarks>
        ///     Only the dispatcher thread may access DispatcherObjects.
        ///     <p/>
        ///     This method is public so that any thread can probe to
        ///     see if it has access to the DispatcherObject.
        /// </remarks>
        /// <returns>
        ///     True if the calling thread has access to this object.
        /// </returns>
        [System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]
        public bool CheckAccess()
        {
            // This method is free-threaded.
 
            bool accessAllowed = true;
            Dispatcher dispatcher = _dispatcher;
 
            // Note: a DispatcherObject that is not associated with a
            // dispatcher is considered to be free-threaded.
            if(dispatcher != null)
            {
                accessAllowed = dispatcher.CheckAccess();
            }
 
            return accessAllowed;
        }
 
        /// <summary>
        ///     Verifies that the calling thread has access to this object.
        /// </summary>
        /// <remarks>
        ///     Only the dispatcher thread may access DispatcherObjects.
        ///     <p/>
        ///     This method is public so that derived classes can probe to
        ///     see if the calling thread has access to itself.
        /// </remarks>
        [System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]
        public void VerifyAccess()
        {
            // This method is free-threaded.
 
            Dispatcher dispatcher = _dispatcher;
 
            // Note: a DispatcherObject that is not associated with a
            // dispatcher is considered to be free-threaded.
            if(dispatcher != null)
            {
                dispatcher.VerifyAccess();
            }
        }
 
        /// <summary>
        ///     Instantiate this object associated with the current Dispatcher.
        /// </summary>
        protected DispatcherObject()
        {
            _dispatcher = Dispatcher.CurrentDispatcher;
        }
 
        private Dispatcher _dispatcher;
        private static Dispatcher _sentinelDispatcher;
    }
}

代码来自：DispatcherObject.cs。

Dispatcher 属性仅仅是在获取 _dispatcher 字段的值，因此我们只需要看 _dispatcher 字段的赋值时机，以及所有给 _dispatcher 赋值的代码。

由于 _dispatcher 字段是私有字段，所以仅需调查这个类本身即可找到所有的赋值时机。（反射等非常规手段需要排除在外，因为这意味着开发者是逗比——自己闯的祸不能怪 WPF 框架。）

赋值时机

先来看看 dispatcher 字段的赋值时机。

DispatcherObject 仅有一个构造函数，而这个构造函数中就已经给 _dispatcher 赋值了，因此其所有的子类的初始化之前，_dispatcher 就会被赋值。

protected DispatcherObject()
{
    _dispatcher = Dispatcher.CurrentDispatcher;
}

那么所赋的值是否可能为 null 呢，这就要看 Dispatcher.CurrentDispatcher 是否可能返回一个 null 了。

以下是 Dispatcher.CurrentDispatcher 的属性获取代码：

public static Dispatcher CurrentDispatcher
{
    get
    {
        // Find the dispatcher for this thread.
        Dispatcher currentDispatcher = FromThread(Thread.CurrentThread);;

        // Auto-create the dispatcher if there is no dispatcher for
        // this thread (if we are allowed to).
        if(currentDispatcher == null)
        {
            currentDispatcher = new Dispatcher();
        }

        return currentDispatcher;
    }
}

可以看到，无论前面的方法得到的值是否是 null，后面都会再给 currentDispatcher 局部变量赋值一个新创建的实例的。因此，此属性是绝对不会返回 null 的。

由此可知，DispatcherObject 自构造起便拥有一个不为 null 的 Dispatcher 属性，其所有子类在初始化之前便会得到不为 null 的 Dispatcher 属性。

后续赋值

现在我们来看看在初始化完成之后，后面是否有可能将 _dispatcher 赋值为 null。

给 _dispatcher 字段的赋值代码仅有两个：

// This method allows certain derived classes to break the dispatcher affinity
// of our objects.
[FriendAccessAllowed] // Built into Base, also used by Framework.
internal void DetachFromDispatcher()
{
    _dispatcher = null;
}

// Make this object a "sentinel" - it can be used in equality tests, but should
// not be used in any other way.  To enforce this and catch bugs, use a special
// sentinel dispatcher, so that calls to CheckAccess and VerifyAccess will
// fail;  this will catch most accidental uses of the sentinel.
[FriendAccessAllowed] // Built into Base, also used by Framework.
internal void MakeSentinel()
{
    _dispatcher = EnsureSentinelDispatcher();
}

第一个 DetachFromDispatcher 很好理解，让 DispatcherObject 跟 Dispatcher 无关。在整个 WPF 的代码中，使用此方法的仅有以下 6 处：

• Freezable.Freeze 实例方法
• BeginStoryboard.Seal 实例方法
• Style.Seal 实例方法
• TriggerBase.Seal 实例方法
• StyleHelper 在 SealTemplate 静态方法中对 FrameworkTemplate 类型的实例调用此方法
• ResourceDictionary 在构造函数中为 DispatcherObject 类型的 DummyInheritanceContext 属性调用此方法

而 Application 类型不是以上任何一个类型的子类（Application 类的直接基类是 DispatcherObject），因此 Application 类中的 Dispatcher 属性不可能因为 DetachFromDispatcher 方法的调用而被赋值为 null。

接下来看看 MakeSentinel 方法，此方法的作用不如上面方法那样直观，实际上它的作用仅仅为了验证某个方法调用时所在的线程是否是符合预期的（给 VerifyAccess 和 CheckAccess 使用）。

使用此方法的仅有 1 处：

• ItemsControl 所用的 ItemInfo 类的静态构造函数

internal static readonly DependencyObject SentinelContainer = new DependencyObject();
internal static readonly DependencyObject UnresolvedContainer = new DependencyObject();
internal static readonly DependencyObject KeyContainer = new DependencyObject();
internal static readonly DependencyObject RemovedContainer = new DependencyObject();

static ItemInfo()
{
    // mark the special DOs as sentinels.  This helps catch bugs involving
    // using them accidentally for anything besides equality comparison.
    SentinelContainer.MakeSentinel();
    UnresolvedContainer.MakeSentinel();
    KeyContainer.MakeSentinel();
    RemovedContainer.MakeSentinel();
}

所有这些使用都与 Application 无关。

结论

总结以上所有的分析：

1. Application 类型的实例在初始化之前，Dispatcher 属性就已经被赋值且不为 null；
2. 所有可能改变 _dispatcher 属性的常规方法均与 Application 类型无关；

因此，所有常规手段均不会让 Application 类的 Dispatcher 属性拿到 null 值。如果你还说拿到了 null，那就检查是否有逗比程序员通过反射或其他手段将 _dispatcher 字段改为了 null 吧……

Application.Current 静态属性

关于 Application.Current 是否可能为 null 的分析，由于比较长，请参见我的另一篇博客：

• WPF 的 Application.Current.Dispatcher 中，Current 可能为 null

参考资料

• DispatcherObject.cs

使用 SetParent 跨进程设置父子窗口时的一些问题（小心卡死）

在微软的官方文档中，说 SetParent 可以在进程内设置，也可以跨进程设置。当使用跨进程设置窗口的父子关系时，你需要注意本文提到的一些问题，避免踩坑。

跨进程设置 SetParent

关于 SetParent 函数设置窗口父子关系的文档可以看这个：

• SetParent function (winuser.h) - Microsoft Docs

在这篇文章的 DPI 感知一段中明确写明了在进程内以及跨进程设置父子关系时的一些行为。虽然没有明确说明支持跨进程设置父子窗口，不过这段文字就几乎说明 Windows 系统对于跨进程设置窗口父子关系还是支持的。

但 Raymond Chen 在 Is it legal to have a cross-process parent/child or owner/owned window relationship? 一文中有另一段文字：

If I remember correctly, the documentation for Set­Parent used to contain a stern warning that it is not supported, but that remark does not appear to be present any more. I have a customer who is reparenting windows between processes, and their application is experiencing intermittent instability.
如果我没记错的话，SetParent 的文档曾经包含一个严厉的警告表明它不受支持，但现在这段备注似乎已经不存在了。我就遇到过一个客户跨进程设置窗口之间的父子关系，然后他们的应用程序间歇性不稳定。

这里表明了 Raymond Chen 对于跨进程设置父子窗口的一些担忧，但从文档趋势来看，还是支持的。只是这种担忧几乎说明跨进程设置 SetParent 存在一些坑。

那么本文就说说跨进程设置父子窗口的一些坑。

消息循环强制同步

消息循环

我们会感觉到 Windows 中某个窗口有响应（比如鼠标点击有反应），是因为这个窗口在处理 Windows 消息。窗口进行消息循环不断地处理消息使得各种各样的用户输入可以被处理，并正确地在界面上显示。

一个典型的消息循环大概像这样：

while(GetMessage(ref msg, IntPtr.Zero, 0, 0))
{
    TranslateMessage(ref msg);
    DispatchMessage(ref msg);
}

对于显示了窗口的某个线程调用了 GetMessage 获取了消息，Windows 系统就会认为这个线程有响应。相反，如果长时间不调用 GetMessage，Windows 就会认为这个线程无响应。TranslateMessage 则是翻译一些消息（比如从按键消息翻译成字符消息）。真正处理 GetMessage 中的内容则是后面的调度消息 DispatchMessage，是这个函数的调用使得我们 UI 界面上的内容可以有可见的反映。

一般来说，每个创建了窗口的线程都有自己独立的消息循环，且不会互相影响。然而一旦这些窗口之间建立了父子关系之后就会变得麻烦起来。

强制同步

Windows 会让具有父子关系的所有窗口的消息循环强制同步。具体指的是，所有具有父子关系的窗口消息循环，其消息循环会串联成一个队列（这样才可以避免消息循环的并发）。

也就是说，如果你有 A、B、C、D 四个窗口，分属不同进程，A 是 B、C、D 窗口的父窗口，那么当 A 在处理消息的时候，B、C、D 的消息循环就会卡在 GetMessage 的调用。同样，无论是 B、C 还是 D 在处理消息的时候，其他窗口也会同样卡在 GetMessage 的调用。这样，所有进程的 UI 线程实际上会互相等待，所有通过消息循环执行的代码都不会同时执行。然而实际上 Windows GUI 应用程序的开发中基本上 UI 代码都是通过消息循环来执行的，所以这几乎等同于所有进程的 UI 线程强制同步成类似一个 UI 线程的效果了。

带来的副作用也就相当明显，任何一个进程卡了 UI，其他进程的 UI 将完全无响应。当然，不依赖消息循环的代码不会受此影响，比如 WPF 应用程序的动画和渲染。

如何解决

对于 SetParent 造成的这些问题，实际上没有官方的解决方案，你需要针对你不同的业务采用不同的解决办法。

正如 Raymond Chen 所说：

(It’s one of those “if you don’t already know what the consequences are, then you are not smart enough to do it correctly” things. You must first become the master of the rules before you can start breaking them.)
正如有些人说的“如果你不知道后果，那么你也不足以正确地完成某件事情”。在开始破坏规则之前，您必须先成为规则的主人。

你必须清楚跨进程设置父子窗口带来的各种副作用，然后针对性地给出解决方案：

1. 比如所有窗口会强制串联成一个队列，那么可以考虑将暂时不显示的窗口断开父子关系；
2. 比如设置窗口的位置大小等操作，必须考虑此窗口不是顶层窗口的问题，需要跨越进程到顶层窗口来操作；

参考资料

• windows - Good or evil - SetParent() win32 API between different processes - Stack Overflow
• Hosting WPF UI cross-thread and cross-process – Diaries of a Software Plumber

• [Is it legal to have a cross-process parent/child or owner/owned window relationship?

  The Old New Thing](https://devblogs.microsoft.com/oldnewthing/?p=4683)

• winapi - Why are “TranslateMessage” and “DispatchMessage” separate calls? - Stack Overflow

System.InvalidOperationException:“BuildWindowCore 无法返回寄宿的子窗口句柄。”

当试图在 WPF 窗口中嵌套显示 Win32 子窗口的时候，你有可能出现错误：“BuildWindowCore 无法返回寄宿的子窗口句柄。”。

这是很典型的 Win32 错误，本文介绍如何修复此错误。

我们在 MainWindow 中嵌入一个其他的窗口来承载新的 WPF 控件。一般情况下我们当然不会这么去做，但是如果我们要跨越进程边界来完成 WPF 渲染内容的融合的时候，就需要嵌入一个新的窗口了。

WPF 中可以使用 HwndSource 来包装一个 WPF 控件到 Win32 窗口，使用自定义的继承自 HwndHost 的类可以把 Win32 窗口包装成 WPF 控件。由于窗口句柄是可以跨越进程边界传递的，所以这样的方式可以完成跨进程的 WPF 控件显示。

问题

你有可能在调试嵌入窗口代码的时候遇到错误：

System.InvalidOperationException:“BuildWindowCore 无法返回寄宿的子窗口句柄。”

英文是：

BuildWindowCore failed to return the hosted child window handle.

原因和解决办法

此异常的原因非常简单，是 HwndSource 的 BuildWindowCore 的返回值有问题。具体来说，就是子窗口的句柄返回了 0。

也就是下面这段代码中 return new HandleRef(this, IntPtr.Zero) 这句，第二个参数是 0。

protected override HandleRef BuildWindowCore(HandleRef hwndParent)
{
    const int WS_CHILD = 1073741824;
    const int WS_CLIPCHILDREN = 33554432;
    var parameters = new HwndSourceParameters("demo")
    {
        ParentWindow = hwndParent.Handle,
        WindowStyle = (int)(WS_CHILD | WS_CLIPCHILDREN),
        TreatAncestorsAsNonClientArea = true,
    };
    var source = new HwndSource(parameters);
    source.RootVisual = new Button();
    return new HandleRef(this, _handle);
}

要解决，就需要传入正确的句柄值。当然上面的代码为了示例，故意传了一个不知道哪里的 _handle，实际上应该传入 source.Handle 才是正确的。

System.InvalidOperationException:“寄宿 HWND 必须是子窗口。”

当试图在 WPF 窗口中嵌套显示 Win32 子窗口的时候，你有可能出现错误：“System.InvalidOperationException:“寄宿 HWND 必须是子窗口。””。

这是很典型的 Win32 错误，本文介绍如何修复此错误。

一个最简的嵌入其他窗口的例子

我们在 MainWindow 中嵌入一个其他的窗口来承载新的 WPF 控件。一般情况下我们当然不会这么去做，但是如果我们要跨越进程边界来完成 WPF 渲染内容的融合的时候，就需要嵌入一个新的窗口了。

WPF 中可以使用 HwndSource 来包装一个 WPF 控件到 Win32 窗口，使用自定义的继承自 HwndHost 的类可以把 Win32 窗口包装成 WPF 控件。由于窗口句柄是可以跨越进程边界传递的，所以这样的方式可以完成跨进程的 WPF 控件显示。

下面是最简单的一个例子，为了简单，没有跨进程传递 Win32 窗口句柄，而是直接创建出来。

using System.Runtime.InteropServices;
using System.Windows;
using System.Windows.Interop;

namespace Walterlv.Demo.HwndWrapping
{
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
            Loaded += OnLoaded;
        }

        private void OnLoaded(object sender, RoutedEventArgs e)
        {
            Content = new HwndWrapper();
        }
    }

    public class HwndWrapper : HwndHost
    {
        private HwndSource _source;

        protected override HandleRef BuildWindowCore(HandleRef hwndParent)
        {
            var parameters = new HwndSourceParameters("walterlv");
            _source = new HwndSource(parameters);
            // 这里的 ChildPage 是一个继承自 UseControl 的 WPF 控件，你可以自己创建自己的 WPF 控件。
            _source.RootVisual = new ChildPage();
            return new HandleRef(this, _source.Handle);
        }

        protected override void DestroyWindowCore(HandleRef hwnd)
        {
            _source?.Dispose();
        }
    }
}

寄宿 HWND 必须是子窗口

当运行此代码的时候，会提示错误：

System.InvalidOperationException:“寄宿 HWND 必须是子窗口。”

或者英文版：

System.InvalidOperationException:”Hosted HWND must be a child window.”

这是一个 Win32 错误，因为我们试图将一个普通的窗口嵌入到另一个窗口中，而实际上要完成嵌入需要子窗口才行。

那么如何设置一个 Win32 窗口为子窗口呢？使用 SetWindowLong 来设置 Win32 窗口的样式是可以的。不过我们因为使用了 HwndSource，所以可以通过 HwndSourceParameters 来更方便地设置窗口样式。

我们需要将 HwndSourceParameters 那一行改成这样：

++  const int WS_CHILD = 0x40000000;
--  var parameters = new HwndSourceParameters("walterlv");
++  var parameters = new HwndSourceParameters("walterlv")
++  {
++      ParentWindow = hwndParent.Handle,
++      WindowStyle = WS_CHILD,
++  };

最关键的是两点：

1. 需要设置此窗口为子窗口，也就是设置 WindowStyle 为 WS_CHILD；
2. 需要设置此窗口的父窗口，也就是设置 ParentWindow 为 hwndParent.Handle（我们使用参数中传入的 hwndParent 作为父窗口）。

现在再运行，即可正常显示此嵌套窗口：

另外，WindowStyle 属性最好加上 WS_CLIPCHILDREN，详情请阅读：

• 解决 WPF 嵌套的子窗口在改变窗口大小的时候闪烁的问题

参考资料

• WPF嵌入式调用Win32应用程序的问题—提示异常：寄宿的HWND必须是指定父级的子窗口

System.InvalidOperationException:“寄宿的 HWND 必须是指定父级的子窗口。”

当试图在 WPF 窗口中嵌套显示 Win32 子窗口的时候，你有可能出现错误：“寄宿的 HWND 必须是指定父级的子窗口。”。

这是很典型的 Win32 错误，本文介绍如何修复此错误。

我们在 MainWindow 中嵌入一个其他的窗口来承载新的 WPF 控件。一般情况下我们当然不会这么去做，但是如果我们要跨越进程边界来完成 WPF 渲染内容的融合的时候，就需要嵌入一个新的窗口了。

WPF 中可以使用 HwndSource 来包装一个 WPF 控件到 Win32 窗口，使用自定义的继承自 HwndHost 的类可以把 Win32 窗口包装成 WPF 控件。由于窗口句柄是可以跨越进程边界传递的，所以这样的方式可以完成跨进程的 WPF 控件显示。

问题

你有可能在调试嵌入窗口代码的时候遇到错误：

System.InvalidOperationException:“寄宿的 HWND 必须是指定父级的子窗口。”

英文是：

Hosted HWND must be a child window of the specified parent.

原因和解决办法

出现此错误，是因为同一个子窗口被两次设置为同一个窗口的子窗口。

具体来说，就是 A 窗口使用 HwndHost 设置成了 B 的子窗口，随后 A 又通过一个新的 HwndHost 设置成了新子窗口。

要解决，则必须确保一个窗口只能使用 HwndHost 设置一次子窗口。

通过 AppSwitch 禁用 WPF 内置的触摸让 WPF 程序可以处理 Windows 触摸消息

WPF 框架自己实现了一套触摸机制，但同一窗口只能支持一套触摸机制，于是这会禁用系统的触摸消息（WM_TOUCH）。这能够很大程度提升 WPF 程序的触摸响应速度，但是很多时候又会产生一些 Bug。

如果你有需要，可以考虑禁用 WPF 的内置的实时触摸（RealTimeStylus）。本文介绍禁用方法，使用 AppSwitch，而不是网上广为流传的反射方法。

如何设置 AppSwitch

在你的应用程序的 app.config 文件中加入 Switch.System.Windows.Input.Stylus.DisableStylusAndTouchSupport=true 开关，即可关闭 WPF 内置的实时触摸，而改用 Windows 触摸消息（WM_TOUCH）。

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Windows.Input.Stylus.DisableStylusAndTouchSupport=true" />
  </runtime>
</configuration>

如果你的解决方案中没有找到 app.config 文件，可以创建一个：

然后，把上面的代码拷贝进去即可。

反射禁用的方法

微软的官方文档也有提到使用放射禁用的方法，但一般不推荐这种调用内部 API 的方式，比较容易在 .NET 的版本更新中出现问题：

• Disable the RealTimeStylus for WPF Applications - Microsoft Docs
• WPF 禁用实时触摸 - 林德熙

此方法可以解决的问题一览

拖拽窗口或者调整窗口大小时不能实时跟随的问题

• Why all my WPF applications fail to drag outside of their windows since Windows 10 (1809/1903) such as resizing the window or do drag drop? - Stack Overflow
• All WPF applications fail to drag outside of their windows since Windows 10 (1809/1903) such as resizing the window or do drag drop · Issue #1323 · dotnet/wpf

在部分设备上启动即崩溃

• .NET 4.7 - WPF - Touch Enabled Devices Crash Applications · Issue #480 · microsoft/dotnet
• Visual Studio may freeze or crash when running on a pen-enabled machine - Developer Community

在透明窗口上触摸会挡住 UWP 程序

• c# - On Windows 10 (1803), all applications lost touch or stylus if a WPF transparent window covers on them - Stack Overflow

参考资料

• Disable the RealTimeStylus for WPF Applications - Microsoft Docs
• WPF-Samples/runtimeconfig.template.json at master · microsoft/WPF-Samples
• All WPF applications fail to drag outside of their windows since Windows 10 (1809/1903) such as resizing the window or do drag drop · Issue #1323 · dotnet/wpf

The VisualBrush of WPF only refresh the visual but not the layout

Now we’ll talk about a behavior of WPF VisualBrush. Maybe it is a bug, but let’s view some details and determine whether it is or not.

The reproduction code

Let’s make a XAML layout to reproduce such an issue.

We have a large Grid which contains an inner Grid and an inner Border. The Grid contains a Rectangle which is as large as the Grid itself and a TextBlock which presents some contents. The Border only shows its background which a VisualBrush of the Grid.

This is the whole XAML file:

<Window x:Class="Walterlv.Demo.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Walterlv 的 WindowChrome 示例窗口" Height="450" Width="800"
        WindowStartupLocation="CenterScreen">
    <Grid>
        <Grid x:Name="VisualSource">
            <Rectangle x:Name="VisibleOr" Fill="LightCoral" Visibility="Visible" />
            <TextBlock FontSize="24" TextAlignment="Center" VerticalAlignment="Center">
                <Run Text="I'm walterlv, " />
                <LineBreak />
                <Run Text="I'm reproducing this Visual bug." />
            </TextBlock>
        </Grid>
        <Border>
            <Border.Background>
                <VisualBrush Visual="{Binding Source={x:Reference VisualSource}}" />
            </Border.Background>
        </Border>
    </Grid>
</Window>

This is the code-behind. Notice that it changes the visibility of the Rectangle every 1 second.

using System.Threading.Tasks;
using System.Windows;

namespace Walterlv.Demo
{
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
            Loaded += OnLoaded;
        }

        private async void OnLoaded(object sender, RoutedEventArgs e)
        {
            while (true)
            {
                await Task.Delay(1000);
                VisibleOr.Visibility = Visibility.Collapsed;
                await Task.Delay(1000);
                VisibleOr.Visibility = Visibility.Visible;
            }
        }
    }
}

To verify the issue

We know that the VisualBrush shows and stretch the whole Visual so we can predicate only two results:

• If the Rectangle is visible with Visibility property Visible, the Border background which contains the VisualBrush will be exactly the same with the Grid.
• If the Rectangle is invisible with Visibility property Collapsed, the Border background which contains the VisualBrush will stretch the whole content to the Border without any area of the Rectangle.

But it is the real result?

The animation picture below shows the result when the Rectangle is visible as the startup:

The animation picture below shows the result when the Rectangle is invisible as the startup:

Did you notice that?

Only at the very beginning when the program runs it behaves the same as we predicted. But when we change the visibility of the Rectangle the layout never changes.

The issue?

I’ve fired this issue into GitHub and this is the link:

• The VisualBrush only refresh the visual but not the layout when the Visual visibility changes · Issue #1241 · dotnet/wpf

WPF 的 VisualBrush 只刷新显示的视觉效果，不刷新布局范围

WPF 的 VisualBrush 可以帮助我们在一个控件中显示另一个控件的外观。这是非常妙的功能。

但是本文需要说其中的一个 Bug —— 如果使用 VisualBrush 显示另一个控件的外观，那么只会在其显示效果有改变的时候刷新，而不会在目标布局改变的时候刷新布局。

用于复现问题的代码

我们现在做一个可以用于验证此问题的布局。

在一个大的 Grid 容器中有一个 Grid 和一个 Border，这个 Grid 将放一个大面积的 Rectangle 和一个表示内容的 TextBlock；而那个 Border 将完全以 VisualBrush 的形式呈现，呈现的内容是此 Grid 中的全部内容。

它的完整 XAML 代码如下：

<Window x:Class="Walterlv.Demo.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Walterlv 的 WindowChrome 示例窗口" Height="450" Width="800"
        WindowStartupLocation="CenterScreen">
    <Grid>
        <Grid x:Name="VisualSource">
            <Rectangle x:Name="VisibleOr" Fill="LightCoral" Visibility="Visible" />
            <TextBlock FontSize="24" TextAlignment="Center" VerticalAlignment="Center">
                <Run Text="I'm walterlv, " />
                <LineBreak />
                <Run Text="I'm reproducing this Visual bug." />
            </TextBlock>
        </Grid>
        <Border>
            <Border.Background>
                <VisualBrush Visual="{Binding Source={x:Reference VisualSource}}" />
            </Border.Background>
        </Border>
    </Grid>
</Window>

其后台 C# 代码如下，包含每隔 1 秒钟切换 Rectangle 可见性的代码。

using System.Threading.Tasks;
using System.Windows;

namespace Walterlv.Demo
{
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
            Loaded += OnLoaded;
        }

        private async void OnLoaded(object sender, RoutedEventArgs e)
        {
            while (true)
            {
                await Task.Delay(1000);
                VisibleOr.Visibility = Visibility.Collapsed;
                await Task.Delay(1000);
                VisibleOr.Visibility = Visibility.Visible;
            }
        }
    }
}

验证问题

我们知道，VisualBrush 在默认情况下会将 Visual 中的全部内容拉伸到控件中显示，于是可以预估出两个可能的结果：

• 如果 Rectangle 可见（Visibility 为 Visible），那么 Border 中以 VisualBrush 显示的内容将完全和下面重叠（因为大小相同，拉伸后正好重叠）。
• 如果 Rectangle 不可见（Visibility 为 Collapsed），那么 Border 中以 VisualBrush 显示的内容将仅有文字且拉伸到整个 Border 范围。

然而实际运行真的是这样子吗？

下面的动图是 Rectangle 初始状态可见时，窗口运行后的结果：

下面的动图是 Rectangle 初始状态不可见时，窗口运行后的结果：

注意到了吗？

只有初始状态才能正确反应我们之前预估出的结果，而无论后面怎么再改变可见性，布局都不会再刷新了。只是——后面 VisualBrush 的内容始终重叠。这意味着 VisualBrush 中目标 Visual 的范围增大之后不会再缩小了。

问题？

这是问题吗？

于是在以下 issue 中跟进此问题：

VisualBrush 的其他 Bug

参见：

• wpf VisualBrush 已知问题 - 林德熙

WPF 很少人知道的科技

本文介绍不那么常见的 WPF 相关的知识。

在 C# 代码中创建 DataTemplate

大多数时候我们只需要在 XAML 中就可以实现我们想要的各种界面效果。这使得你可能已经不知道如何在 C# 代码中创建同样的内容。

比如在代码中创建 DataTemplate，主要会使用到 FrameworkElementFactory 类型。

可以参考：

• WPF 后台创建 DateTemplate - Iron 的博客 - CSDN博客

多个数据源合并为一个列表显示

WPF 提供 CompositionCollection 用于将多个列表合并为一个，以便在 WPF 界面的同一个列表中显示多个数据源的数据。

<ListBox Name="WalterlvDemoListBox">
    <ListBox.Resources>
        <CollectionViewSource x:Key="Items1Source" Source="{Binding Items1}"/>
        <CollectionViewSource x:Key="Items2Source" Source="{Binding Items2}"/>
    </ListBox.Resources>
    <ListBox.ItemsSource>
        <CompositeCollection>
            <CollectionContainer Collection="{Binding Source={StaticResource Items1Source}}" />
            <CollectionContainer Collection="{Binding Source={StaticResource Items2Source}}" />
            <ListBoxItem>Walterlv End Item 1</ListBoxItem>
            <ListBoxItem>Walterlv End Item 2</ListBoxItem>
        </CompositeCollection>
    </ListBox.ItemsSource>
</ListBox>

关于 CompositeCollection 的使用示例可以参考：

• How to: Implement a CompositeCollection - Microsoft Docs

神樹桜乃写了一份非 WPF 框架的版本，如果希望在非 WPF 程序中使用，可以参考：

• Sakuno.Base/ConcatenatedCollectionView`T.cs at master · KodamaSakuno/Sakuno.Base

使用附加属性做缓存，避免内存泄漏

在没有使用 WPF 的时候，如果我们要为一个对象添加属性或者行为，我们可能会使用字典来实现。但字典带来了内存泄漏的问题，要自己处理内存泄漏问题可能会写比较复杂的代码。

然而，WPF 的附加属性可以非常容易地为对象添加属性或者行为，而且也不用担心内存泄漏问题。

例如，我曾经用 WPF 来模拟 UWP 流畅设计（Fluent Design）中的光照效果，使用附加属性来管理此行为则完全不用担心内存泄漏问题：

• 流畅设计 Fluent Design System 中的光照效果 RevealBrush，WPF 也能模拟实现啦！

使用 ConditionalWeakTable 做非 WPF 版本的缓存

如果你有一些非 WPF 的对象需要做类似 WPF 那种附加属性，那么可以考虑使用 ConditionalWeakTable 来实现，Key 是那个对象，而 Value 是你需要附加的属性或者行为。

这里的引用关系是 Key 引用着 Value，如果 Key 被回收，那么 Value 也可以被回收。

• .NET/C# 使用 ConditionalWeakTable 附加字段（CLR 版本的附加属性，也可用用来当作弱引用字典 WeakDictionary）

使用代码模拟触摸

WPF 默认情况下的触摸是通过 COM 组件 PimcManager 获取到的，在禁用实时触摸后会启用系统的 TOUCH 消息获取到，如果开启了 Pointer 消息那么会使用 POINTER 消息。

我们可以继承自 TouchDevice 来模拟触摸，详见：

• WPF 模拟触摸设备

模拟 UWP 界面

在现有的 Windowing API 下，系统中看起来非常接近系统级的窗口样式可能都是用不同技术模拟实现的，只是模拟得很像而已。

如果要将 WPF 模拟得很像 UWP，可以参考我的这两篇博客：

• WPF 使用 WindowChrome，在自定义窗口标题栏的同时最大程度保留原生窗口样式（类似 UWP/Chrome）
• WPF 应用完全模拟 UWP 的标题栏按钮

模拟 Fluent Design 特效

目前 WPF 还不能直接使用 Windows 10 Fluent Design 特效。当然如果你的程序非常小，那么模拟一下也不会伤害太多性能：

• 流畅设计 Fluent Design System 中的光照效果 RevealBrush，WPF 也能模拟实现啦！
• 在 Windows 10 上为 WPF 窗口添加模糊特效

然而充分利用 Fluent Design 的高性能，需要上 XAML Islands，详见：

• [Using the UWP XAML hosting API in a desktop application - Windows apps

  Microsoft Docs](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/using-the-xaml-hosting-api)

如何追踪 WPF 程序中当前获得键盘焦点的元素并显示出来

我们有很多的调试工具可以帮助我们查看 WPF 窗口中当前获得键盘焦点的元素。本文介绍监控当前键盘焦点元素的方法，并且提供一个不需要任何调试工具的自己绘制键盘焦点元素的方法。

使用调试工具查看当前获得键盘焦点的元素

Visual Studio 带有实时可视化树的功能，使用此功能调试 WPF 程序的 UI 非常方便。

在打开实时可视化树后，我们可以略微认识一下这里的几个常用按钮：

这里，我们需要打开两个按钮：

• 为当前选中的元素显示外框
• 追踪具有焦点的元素

这样，只要你的应用程序当前获得焦点的元素发生了变化，就会有一个表示这个元素所在位置和边距的叠加层显示在窗口之上。

你可能已经注意到了，Visual Studio 附带的这一叠加层会导致鼠标无法穿透操作真正具有焦点的元素。这显然不能让这一功能一直打开使用，这是非常不方便的。

使用代码查看当前获得键盘焦点的元素

我们打算在代码中编写追踪焦点的逻辑。这可以规避 Visual Studio 中叠加层中的一些问题，同时还可以在任何环境下使用，而不用担心有没有装 Visual Studio。

获取当前获得键盘焦点的元素：

var focusedElement = Keyboard.FocusedElement;

不过只是拿到这个值并没有多少意义，我们需要：

1. 能够实时刷新这个值；
2. 能够将这个控件在界面上显示出来。

实时刷新

Keyboard 有路由事件可以监听，得知元素已获得键盘焦点。

Keyboard.AddGotKeyboardFocusHandler(xxx, OnGotFocus);

这里的 xxx 需要替换成监听键盘焦点的根元素。实际上，对于窗口来说，这个根元素可以唯一确定，就是窗口的根元素。于是我可以写一个辅助方法，用于找到这个窗口的根元素：

// 用于存储当前已经获取过的窗口根元素。
private FrameworkElement _root;

// 获取当前窗口的根元素。
private FrameworkElement Root => _root ?? (_root = FindRootVisual(this));

// 一个辅助方法，用于根据某个元素为起点查找当前窗口的根元素。
private static FrameworkElement FindRootVisual(FrameworkElement source) =>
    (FrameworkElement)((HwndSource)PresentationSource.FromVisual(source)).RootVisual;

于是，监听键盘焦点的代码就可以变成：

Keyboard.AddGotKeyboardFocusHandler(Root, OnGotFocus);

void OnGotFocus(object sender, KeyboardFocusChangedEventArgs e)
{
    if (e.NewFocus is FrameworkElement fe)
    {
        // 在这里可以输出或者显示这个获得了键盘焦点的元素。
    }
}

显示

为了显示一个跟踪焦点的控件，我写了一个 UserControl，里面的主要代码是：

<Canvas IsHitTestVisible="False">
    <Border x:Name="FocusBorder" BorderBrush="#80159f5c" BorderThickness="4"
            HorizontalAlignment="Left" VerticalAlignment="Top"
            IsHitTestVisible="False" SnapsToDevicePixels="True">
        <Border x:Name="OffsetBorder" Background="#80159f5c"
                Margin="-200 -4 -200 -4" Padding="12 0"
                HorizontalAlignment="Center" VerticalAlignment="Bottom"
                SnapsToDevicePixels="True">
            <Border.RenderTransform>
                <TranslateTransform x:Name="OffsetTransform" Y="16" />
            </Border.RenderTransform>
            <TextBlock x:Name="FocusDescriptionTextBlock" Foreground="White" HorizontalAlignment="Center" />
        </Border>
    </Border>
</Canvas>

using System;
using System.Runtime.InteropServices;
using System.Text;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Input;
using System.Windows.Interop;
using System.Windows.Threading;

namespace Walterlv.Windows
{
    public partial class KeyboardFocusView : UserControl
    {
        public KeyboardFocusView()
        {
            InitializeComponent();
            Loaded += OnLoaded;
            Unloaded += OnUnloaded;
        }

        private void OnLoaded(object sender, RoutedEventArgs e)
        {
            if (Keyboard.FocusedElement is FrameworkElement fe)
            {
                SetFocusVisual(fe);
            }
            Keyboard.AddGotKeyboardFocusHandler(Root, OnGotFocus);
        }

        private void OnUnloaded(object sender, RoutedEventArgs e)
        {
            Keyboard.RemoveGotKeyboardFocusHandler(Root, OnGotFocus);
            _root = null;
        }

        private void OnGotFocus(object sender, KeyboardFocusChangedEventArgs e)
        {
            if (e.NewFocus is FrameworkElement fe)
            {
                SetFocusVisual(fe);
            }
        }

        private void SetFocusVisual(FrameworkElement fe)
        {
            var topLeft = fe.TranslatePoint(new Point(), Root);
            var bottomRight = fe.TranslatePoint(new Point(fe.ActualWidth, fe.ActualHeight), Root);
            var isOnTop = topLeft.Y < 16;
            var isOnBottom = bottomRight.Y > Root.ActualHeight - 16;

            var bounds = new Rect(topLeft, bottomRight);
            Canvas.SetLeft(FocusBorder, bounds.X);
            Canvas.SetTop(FocusBorder, bounds.Y);
            FocusBorder.Width = bounds.Width;
            FocusBorder.Height = bounds.Height;

            FocusDescriptionTextBlock.Text = string.IsNullOrWhiteSpace(fe.Name)
                ? $"{fe.GetType().Name}"
                : $"{fe.Name}({fe.GetType().Name})";
        }

        private FrameworkElement _root;

        private FrameworkElement Root => _root ?? (_root = FindRootVisual(this));

        private static FrameworkElement FindRootVisual(FrameworkElement source) =>
            (FrameworkElement)((HwndSource)PresentationSource.FromVisual(source)).RootVisual;
    }
}

这样，只要将这个控件放到窗口中，这个控件就会一直跟踪窗口中的当前获得了键盘焦点的元素。当然，为了最好的显示效果，你需要将这个控件放到最顶层。

绘制并实时显示 WPF 程序中当前键盘焦点的元素

如果我们需要监听应用程序中所有窗口中的当前获得键盘焦点的元素怎么办呢？我们需要给所有当前激活的窗口监听 GotKeyboardFocus 事件。

于是，你需要我在另一篇博客中写的方法来监视整个 WPF 应用程序中的所有窗口：

• 如何监视 WPF 中的所有窗口，在所有窗口中订阅事件或者附加 UI

里面有一段对 ApplicationWindowMonitor 类的使用：

var app = Application.Current;
var monitor = new ApplicationWindowMonitor(app);
monitor.ActiveWindowChanged += OnActiveWindowChanged;

void OnActiveWindowChanged(object sender, ActiveWindowEventArgs e)
{
    var newWindow = e.NewWindow;
    // 一旦有一个新的获得焦点的窗口出现，就可以在这里执行一些代码。
}

于是，我们只需要在 OnActiveWindowChanged 事件中，将我面前面写的控件 KeyboardFocusView 从原来的窗口中移除，然后放到新的窗口中即可监视新的窗口中的键盘焦点。

由于每一次的窗口激活状态的切换都会更新当前激活的窗口，所以，我们可以监听整个 WPF 应用程序中所有窗口中的键盘焦点。

如何监视 WPF 中的所有窗口，在所有窗口中订阅事件或者附加 UI

由于 WPF 路由事件（主要是隧道和冒泡）的存在，我们很容易能够通过只监听窗口中的某些事件使得整个窗口中所有控件发生的事件都被监听到。然而，如果我们希望监听的是整个应用程序中所有的事件呢？路由事件的路由可并不会跨越窗口边界呀？

本文将介绍我编写的应用程序窗口监视器，来监听整个应用程序中所有窗口中的路由事件。这样的方法可以用来无时无刻监视 WPF 程序的各种状态。

其实问题依旧摆在那里，因为我们依然无法让路由事件跨越窗口边界。更麻烦的是，我们甚至不知道应用程序有哪些窗口，这些窗口都是什么时机显示出来的。

Application 类中有一个属性 Windows，这是一个 WindowCollection 类型的属性，可以用来获取当前已经被 Application 类管理的所有的窗口的集合。当然 Application 类内部还有一个属性 NonAppWindowsInternal 用来管理与此 Application 没有逻辑关系的窗口集合。

于是，我们只需要遍历 Windows 集合便可以获得应用程序中的所有窗口，然后对每一个窗口监听需要的路由事件。

var app = Application.Current;
foreach (Window window in app.Windows)
{
    // 在这里监听窗口中的事件。
}

等等！这种操作意味着将来新打开的窗口是不会被监听到事件的。

我们有没有方法拿到新窗口的显示事件呢？遗憾的是——并不行。

但是，我们有一些变相的处理思路。比如，由于 Windows 系统的特性，整个用户空间内，统一时刻只能有一个窗口能处于激活状态。我们可以利用当前窗口的激活与非激活的切换时机再去寻找新的窗口。

于是，一开始的时候，我们可以监听一些窗口的激活事件。如果执行这段初始化代码的时候没有任何窗口是激活的状态，那么就监听所有窗口的激活事件；如果有一个窗口是激活的，那么就监听这个窗口的取消激活事件。

private void InitializeActivation()
{
    var app = Application.Current;
    var availableWindows = app.Windows.ToList();
    var activeWindow = availableWindows.FirstOrDefault(x => x.IsActive);
    if (activeWindow == null)
    {
        foreach (var window in availableWindows)
        {
            window.Activated -= Window_Activated;
            window.Activated += Window_Activated;
        }
    }
    else
    {
        activeWindow.Deactivated -= Window_Deactivated;
        activeWindow.Deactivated += Window_Deactivated;
        UpdateActiveWindow(activeWindow);
    }
}

private void UpdateActiveWindow(Window window)
{
    // 当前激活的窗口已经发生了改变，可以在这里为新的窗口做一些事情了。
}

在 Window_Activated 和 Window_Deactivated 事件中，我们主要也是在做初始化。

现在思路基本上全部清晰了，于是我将我写的 ApplicationWindowMonitor 类的全部源码贴出来。

using System;
using System.Linq;
using System.Windows;
using System.Windows.Threading;

namespace Walterlv.Windows
{
    public sealed class ApplicationWindowMonitor
    {
        private readonly Application _app;
        private readonly Predicate<Window> _windowFilter;
        private Window _lastActiveWindow;

        public ApplicationWindowMonitor(Application app, Predicate<Window> windowFilter = null)
        {
            _app = app ?? throw new ArgumentNullException(nameof(app));
            _windowFilter = windowFilter;
            _app.Dispatcher.InvokeAsync(InitializeActivation, DispatcherPriority.Send);
        }

        private void InitializeActivation()
        {
            var availableWindows = _app.Windows.OfType<Window>().Where(FilterWindow).ToList();
            var activeWindow = availableWindows.FirstOrDefault(x => x.IsActive);
            if (activeWindow == null)
            {
                foreach (var window in availableWindows)
                {
                    window.Activated -= Window_Activated;
                    window.Activated += Window_Activated;
                }
            }
            else
            {
                activeWindow.Deactivated -= Window_Deactivated;
                activeWindow.Deactivated += Window_Deactivated;
                UpdateActiveWindow(activeWindow);
            }
        }

        private void Window_Activated(object sender, EventArgs e)
        {
            var window = (Window) sender;
            window.Activated -= Window_Activated;
            window.Deactivated -= Window_Deactivated;
            window.Deactivated += Window_Deactivated;
            UpdateActiveWindow(window);
        }

        private void Window_Deactivated(object sender, EventArgs e)
        {
            var availableWindows = _app.Windows.OfType<Window>().Where(FilterWindow).ToList();
            foreach (var window in availableWindows)
            {
                window.Deactivated -= Window_Deactivated;
                window.Activated -= Window_Activated;
                window.Activated += Window_Activated;
            }
        }

        private void UpdateActiveWindow(Window window)
        {
            if (!Equals(window, _lastActiveWindow))
            {
                try
                {
                    OnActiveWindowChanged(_lastActiveWindow, window);
                }
                finally
                {
                    _lastActiveWindow = window;
                }
            }
        }

        private bool FilterWindow(Window window) => _windowFilter == null || _windowFilter(window);

        public event EventHandler<ActiveWindowEventArgs> ActiveWindowChanged;

        private void OnActiveWindowChanged(Window oldWindow, Window newWindow)
        {
            ActiveWindowChanged?.Invoke(this, new ActiveWindowEventArgs(oldWindow, newWindow));
        }
    }
}

使用方法是：

var app = Application.Current;
var monitor = new ApplicationWindowMonitor(app);
monitor.ActiveWindowChanged += OnActiveWindowChanged;

void OnActiveWindowChanged(object sender, ActiveWindowEventArgs e)
{
    var newWindow = e.NewWindow;
    // 一旦有一个新的获得焦点的窗口出现，就可以在这里执行一些代码。
}

另外，我在 ApplicationWindowMonitor 的构造函数中加入了一个过滤窗口的委托。比如你可以让窗口的监听只对主要的几个窗口生效，而对一些信息提示窗口忽略等等。

从零开始制作 NuGet 源代码包（全面支持 .NET Core / .NET Framework / WPF 项目）

默认情况下，我们打包 NuGet 包时，目标项目安装我们的 NuGet 包会引用我们生成的库文件（dll）。除此之外，我们也可以专门做 NuGet 工具包，还可以做 NuGet 源代码包。然而做源代码包可能是其中最困难的一种了，目标项目安装完后，这些源码将直接随目标项目一起编译。

本文将从零开始，教你制作一个支持 .NET 各种类型项目的源代码包。

前置知识

在开始制作一个源代码包之间，建议你提前了解项目文件的一些基本概念：

• 理解 C# 项目 csproj 文件格式的本质和编译流程

当然就算不了解也没有关系。跟着本教程你也可以制作出来一个源代码包，只不过可能遇到了问题的时候不容易调试和解决。

制作一个源代码包

接下来，我们将从零开始制作一个源代码包。

我们接下来的将创建一个完整的解决方案，这个解决方案包括：

1. 一个将打包成源代码包的项目
2. 一个调试专用的项目（可选）
3. 一个测试源代码包的项目（可选）

第一步：创建一个 .NET 项目

像其他 NuGet 包的引用项目一样，我们需要创建一个空的项目。不过差别是我们需要创建的是控制台程序。

当创建好之后，Main 函数中的所有内容都是不需要的，于是我们删除 Main 函数中的所有内容但保留 Main 函数。

这时 Program.cs 中的内容如下：

namespace Walterlv.PackageDemo.SourceCode
{
    class Program
    {
        static void Main(string[] args)
        {
        }
    }
}

双击创建好的项目的项目，或者右键项目 “编辑项目文件”，我们可以编辑此项目的 csproj 文件。

在这里，我将目标框架改成了 net48。实际上如果我们不制作动态源代码生成，那么这里无论填写什么目标框架都不重要。在这篇博客中，我们主要篇幅都会是做静态源代码生成，所以你大可不必关心这里填什么。

提示：如果 net48 让你无法编译这个项目，说明你电脑上没有装 .NET Framework 4.8 框架，请改成 net473, net472, net471, net47, net462, net 461, net46, net45, netcoreapp3.0, netcoreapp2.1, netcoreapp2.0 中的任何一个可以让你编译通过的目标框架即可。

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net48</TargetFramework>
  </PropertyGroup>

</Project>

第二步：组织项目的目录结构

接下来，我们会让这个项目像一个 NuGet 包的样子。当然，是 NuGet 源代码包。

请在你的项目当中创建这些文件和文件夹：

- Assets
    - build
        + Package.props
        + Package.targets
    - buildMultiTargeting
        + Package.props
        + Package.targets
    - src
        + Foo.cs
    - tools
+ Program.cs

在这里，- 号表示文件夹，+ 号表示文件。

Program.cs 是我们一开始就已经有的，可以不用管。src 文件夹里的 Foo.cs 是我随意创建的一个类，你就想往常创建正常的类文件一样创建一些类就好了。

比如我的 Foo.cs 里面的内容很简单：

using System;

namespace Walterlv.PackageDemo.SourceCode
{
    internal class Foo
    {
        public static void Print() => Console.WriteLine("Walterlv is a 逗比.");
    }
}

props 和 targets 文件你可能在 Visual Studio 的新建文件的模板中找不到这样的模板文件。这不重要，你随便创建一个文本文件，然后将名称修改成上面列举的那样即可。接下来我们会依次修改这些文件中的所有内容，所以无需担心模板自动为我们生成了哪些内容。

为了更直观，我将我的解决方案截图贴出来，里面包含所有这些文件和文件夹的解释。

我特别说明了哪些文件和文件夹是必须存在的，哪些文件和文件夹的名称一定必须与本文说明的一样。如果你是以教程的方式阅读本文，建议所有的文件和文件夹都跟我保持一样的结构和名称；如果你已经对 NuGet 包的结构有一定了解，那么可自作主张修改一些名称。

第三步：编写项目文件 csproj

现在，我们要双击项目名称或者右键“编辑项目文件”来编辑项目的 csproj 文件

我们编辑项目文件的目的，是让我们前一步创建的项目文件夹结构真正成为 NuGet 包中的文件夹结构。

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net48</TargetFramework>

    <!-- 要求此项目编译时要生成一个 NuGet 包。-->
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>

    <!-- 这里为了方便，我将 NuGet 包的输出路径设置在了解决方案根目录的 bin 文件夹下，而不是项目的 bin 文件夹下。-->
    <PackageOutputPath>..\bin\$(Configuration)</PackageOutputPath>

    <!-- 创建 NuGet 包时，项目的输出文件对应到 NuGet 包的 tools 文件夹，这可以避免目标项目引用我们的 NuGet 包的输出文件。
         同时，如果将来我们准备动态生成源代码，而不只是引入静态源代码，还可以有机会运行我们 Program 中的 Main 函数。-->
    <BuildOutputTargetFolder>tools</BuildOutputTargetFolder>

    <!-- 此包将不会传递依赖。意味着如果目标项目安装了此 NuGet 包，那么安装目标项目包的项目不会间接安装此 NuGet 包。-->
    <DevelopmentDependency>true</DevelopmentDependency>
    
    <!-- 包的版本号，我们设成了一个预览版；当然你也可以设置为正式版，即没有后面的 -alpha 后缀。-->
    <Version>0.1.0-alpha</Version>
    
    <!-- 设置包的作者。在上传到 nuget.org 之后，如果作者名与 nuget.org 上的账号名相同，其他人浏览包是可以直接点击链接看作者页面。-->
    <Authors>walterlv</Authors>

    <!-- 设置包的组织名称。我当然写成我所在的组织 dotnet 职业技术学院啦。-->
    <Company>dotnet-campus</Company>
  </PropertyGroup>

  <!-- 在生成 NuGet 包之前，我们需要将我们项目中的文件夹结构一一映射到 NuGet 包中。-->
  <Target Name="IncludeAllDependencies" BeforeTargets="_GetPackageFiles">
    <ItemGroup>

      <!-- 将 Package.props / Package.targets 文件的名称在 NuGet 包中改为需要的真正名称。
           因为 NuGet 包要自动导入 props 和 targets 文件，要求文件的名称必须是 包名.props 和 包名.targets；
           然而为了避免我们改包名的时候还要同步改四个文件的名称，所以就在项目文件中动态生成。-->
      <None Include="Assets\build\Package.props" Pack="True" PackagePath="build\$(PackageId).props" />
      <None Include="Assets\build\Package.targets" Pack="True" PackagePath="build\$(PackageId).targets" />
      <None Include="Assets\buildMultiTargeting\Package.props" Pack="True" PackagePath="buildMultiTargeting\$(PackageId).props" />
      <None Include="Assets\buildMultiTargeting\Package.targets" Pack="True" PackagePath="buildMultiTargeting\$(PackageId).targets" />

      <!-- 我们将 src 目录中的所有源代码映射到 NuGet 包中的 src 目录中。-->
      <None Include="Assets\src\**" Pack="True" PackagePath="src" />

    </ItemGroup>
  </Target>

</Project>

第四步：编写编译文件 targets

接下来，我们将编写编译文件 props 和 targets。注意，我们需要写的是四个文件的内容，不要弄错了。

如果我们做好的 NuGet 源码包被其他项目使用，那么这四个文件中的其中一对会在目标项目被自动导入（Import）。在你理解 理解 C# 项目 csproj 文件格式的本质和编译流程 一文内容之前，你可能不明白“导入”是什么意思。但作为从零开始的入门博客，你也不需要真的理解导入是什么意思，只要知道这四个文件中的代码将在目标项目编译期间运行就好。

buildMultiTargeting 文件夹中的 Package.props 文件

你只需要将下面的代码拷贝到 buildMultiTargeting 文件夹中的 Package.props 文件即可。注意将包名换成你自己的包名，也就是项目名。

<Project>

  <PropertyGroup>
    <MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileFullPath)</MSBuildAllProjects>
  </PropertyGroup>
  
  <!-- 为了简单起见，如果导入了这个文件，那么我们将直接再导入 ..\build\Walterlv.PackageDemo.SourceCode.props 文件。
       注意到了吗？我们并没有写 Package.props，因为我们在第三步编写项目文件时已经将这个文件转换为真实的包名了。-->
  <Import Project="..\build\Walterlv.PackageDemo.SourceCode.props" />

</Project>

buildMultiTargeting 文件夹中的 Package.targets 文件

你只需要将下面的代码拷贝到 buildMultiTargeting 文件夹中的 Package.targets 文件即可。注意将包名换成你自己的包名，也就是项目名。

<Project>

  <PropertyGroup>
    <MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileFullPath)</MSBuildAllProjects>
  </PropertyGroup>
  
  <!-- 为了简单起见，如果导入了这个文件，那么我们将直接再导入 ..\build\Walterlv.PackageDemo.SourceCode.targets 文件。
       注意到了吗？我们并没有写 Package.targets，因为我们在第三步编写项目文件时已经将这个文件转换为真实的包名了。-->
  <Import Project="..\build\Walterlv.PackageDemo.SourceCode.targets" />

</Project>

build 文件夹中的 Package.props 文件

下面是 build 文件夹中 Package.props 文件的全部内容。可以注意到我们几乎没有任何实质性的代码在里面。即便我们在此文件中还没有写任何代码，依然需要创建这个文件，因为后面第五步我们将添加更复杂的代码时将再次用到这个文件完成里面的内容。

现在，保持你的文件中的内容与下面一模一样就好。

<Project>

  <PropertyGroup>
    <MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileFullPath)</MSBuildAllProjects>
  </PropertyGroup>

</Project>

build 文件夹中的 Package.targets 文件

下面是 build 文件夹中的 Package.targets 文件的全部内容。

我们写了两个编译目标，即 Target。_WalterlvDemoEvaluateProperties 没有指定任何执行时机，但帮我们计算了两个属性：

• _WalterlvDemoRoot 即 NuGet 包的根目录
• _WalterlvDemoSourceFolder 即 NuGet 包中的源代码目录

另外，我们添加了一个 Message 任务，用于在编译期间显示一条信息，这对于调试来说非常方便。

_WalterlvDemoIncludeSourceFiles 这个编译目标指定在 CoreCompile 之前执行，并且执行需要依赖于 _WalterlvDemoEvaluateProperties 编译目标。这意味着当编译执行到 CoreCompile 步骤时，将在它执行之前插入 _WalterlvDemoIncludeSourceFiles 编译目标来执行，而 _WalterlvDemoIncludeSourceFiles 依赖于 _WalterlvDemoEvaluateProperties，于是 _WalterlvDemoEvaluateProperties 会插入到更之前执行。那么在微观上来看，这三个编译任务的执行顺序将是：_WalterlvDemoEvaluateProperties -> _WalterlvDemoIncludeSourceFiles -> CoreCompile。

_WalterlvDemoIncludeSourceFiles 中，我们定义了一个集合 _WalterlvDemoCompile，集合中包含 NuGet 包源代码文件夹中的所有 .cs 文件。另外，我们又定义了 Compile 集合，将 _WalterlvDemoCompile 集合中的所有内容添加到 Compile 集合中。Compile 是 .NET 项目中的一个已知集合，当 CoreCompile 执行时，所有 Compile 集合中的文件将参与编译。注意到我没有直接将 NuGet 包中的源代码文件引入到 Compile 集合中，而是经过了中转。后面第五步中，你将体会到这样做的作用。

我们也添加一个 Message 任务，用于在编译期间显示信息，便于调试。

<Project>

  <PropertyGroup>
    <MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileFullPath)</MSBuildAllProjects>
  </PropertyGroup>

  <Target Name="_WalterlvDemoEvaluateProperties">
    <PropertyGroup>
      <_WalterlvDemoRoot>$(MSBuildThisFileDirectory)..\</_WalterlvDemoRoot>
      <_WalterlvDemoSourceFolder>$(MSBuildThisFileDirectory)..\src\</_WalterlvDemoSourceFolder>
    </PropertyGroup>
    <Message Text="1. 初始化源代码包的编译属性" />
  </Target>

  <!-- 引入 C# 源码。 -->
  <Target Name="_WalterlvDemoIncludeSourceFiles"
          BeforeTargets="CoreCompile"
          DependsOnTargets="_WalterlvDemoEvaluateProperties">
    <ItemGroup>
      <_WalterlvDemoCompile Include="$(_WalterlvDemoSourceFolder)**\*.cs" />
      <Compile Include="@(_WalterlvDemoCompile)" />
    </ItemGroup>
    <Message Text="2 引入源代码包中的所有源代码：@(_WalterlvDemoCompile)" />
  </Target>

</Project>

这四个文件分别的作用

我们刚刚花了很大的篇幅教大家完成 props 和 targets 文件，那么这四个文件是做什么的呢？

如果安装我们源代码包的项目使用 TargetFramework 属性写目标框架，那么 NuGet 会自动帮我们导入 build 文件夹中的两个编译文件。如果安装我们源代码包的项目使用 TargetFrameworks（注意复数形式）属性写目标框架，那么 NuGet 会自动帮我们导入 buildMultiTargeting 文件夹中的两个编译文件。

如果你对这个属性不熟悉，请回到第一步看我们一开始创建的代码，你会看到这个属性的设置的。如果还不清楚，请阅读博客：

• 让一个 csproj 项目指定多个开发框架

体验和查看 NuGet 源代码包

也许你已经从本文拷贝了很多代码过去了，但直到目前我们还没有看到这些代码的任何效果，那么现在我们就可以来看看了。这可算是一个阶段性成果呢！

先编译生成一下我们一直在完善的项目，我们就可以在解决方案目录的 bin\Debug 目录下找到一个 NuGet 包。

现在，我们要打开这个 NuGet 包看看里面的内容。你需要先去应用商店下载 NuGet Package Explorer，装完之后你就可以开始直接双击 NuGet 包文件，也就是 nupkg 文件。现在我们双击打开看看。

我们的体验到此为止。如果你希望在真实的项目当中测试，可以阅读其他博客了解如何在本地测试 NuGet 包。

第五步：加入 WPF 项目支持

截至目前，我们只是在源代码包中引入了 C# 代码。如果我们需要加入到源代码包中的代码包含 WPF 的 XAML 文件，或者安装我们源代码包的目标项目包含 WPF 的 XAML 文件，那么这个 NuGet 源代码包直接会导致无法编译通过。至于原因，你需要阅读我的另一篇博客来了解：

• WPF 程序的编译过程

即便你不懂 WPF 程序的编译过程，你也可以继续完成本文的所有内容，但可能就不会明白为什么接下来我们要那样去修改我们之前创建的文件。

接下来我们将修改这些文件：

• build 文件夹中的 Package.props 文件
• build 文件夹中的 Package.targets 文件

build 文件夹中的 Package.props 文件

在这个文件中，我们将新增一个属性 ShouldFixNuGetImportingBugForWpfProjects。这是我取的名字，意为“是否应该修复 WPF 项目中 NuGet 包自动导入的问题”。

我做一个开关的原因是怀疑我们需要针对 WPF 项目进行特殊处理是 WPF 项目自身的 Bug，如果将来 WPF 修复了这个 Bug，那么我们将可以直接通过此开关来关闭我们在这一节做的特殊处理。另外，后面我们将采用一些特别的手段来调试我们的 NuGet 源代码包，在调试项目中我们也会将这个属性设置为 False 以关闭 WPF 项目的特殊处理。

    <Project>
    
      <PropertyGroup>
        <MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileFullPath)</MSBuildAllProjects>
    
++      <!-- 当生成 WPF 临时项目时，不会自动 Import NuGet 中的 props 和 targets 文件，这使得在临时项目中你现在看到的整个文件都不会参与编译。
++           然而，我们可以通过欺骗的方式在主项目中通过 _GeneratedCodeFiles 集合将需要编译的文件传递到临时项目中以间接参与编译。
++           WPF 临时项目不会 Import NuGet 中的 props 和 targets 可能是 WPF 的 Bug，也可能是刻意如此。
++           所以我们通过一个属性开关 `ShouldFixNuGetImportingBugForWpfProjects` 来决定是否修复这个错误。-->
++      <ShouldFixNuGetImportingBugForWpfProjects Condition=" '$(ShouldFixNuGetImportingBugForWpfProjects)' == '' ">True</ShouldFixNuGetImportingBugForWpfProjects>
++    </PropertyGroup>
    
    </Project>

build 文件夹中的 Package.targets 文件

请按照下面的差异说明来修改你的 Package.targets 文件。实际上我们几乎删除任何代码，所以其实你可以将下面的所有内容作为你的新的 Package.targets 中的内容。

    <Project>
    
      <PropertyGroup>
        <MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileFullPath)</MSBuildAllProjects>
      </PropertyGroup>

++    <PropertyGroup>
++      <!-- 我们增加了一个属性，用于处理 WPF 特殊项目的源代码之前，确保我们已经收集到所有需要引入的源代码。 -->
++      <_WalterlvDemoImportInWpfTempProjectDependsOn>_WalterlvDemoIncludeSourceFiles</_WalterlvDemoImportInWpfTempProjectDependsOn>
++    </PropertyGroup>
    
      <Target Name="_WalterlvDemoEvaluateProperties">
        <PropertyGroup>
          <_WalterlvDemoRoot>$(MSBuildThisFileDirectory)..\</_WalterlvDemoRoot>
          <_WalterlvDemoSourceFolder>$(MSBuildThisFileDirectory)..\src\</_WalterlvDemoSourceFolder>
        </PropertyGroup>
        <Message Text="1. 初始化源代码包的编译属性" />
      </Target>
    
      <!-- 引入 C# 源码。 -->
      <Target Name="_WalterlvDemoIncludeSourceFiles"
              BeforeTargets="CoreCompile"
              DependsOnTargets="_WalterlvDemoEvaluateProperties">
        <ItemGroup>
          <_WalterlvDemoCompile Include="$(_WalterlvDemoSourceFolder)**\*.cs" />
++        <_WalterlvDemoAllCompile Include="@(_WalterlvDemoCompile)" />
          <Compile Include="@(_WalterlvDemoCompile)" />
        </ItemGroup>
--      <Message Text="2 引入源代码包中的所有源代码：@(_WalterlvDemoCompile)" />
++      <Message Text="2.1 引入源代码包中的所有源代码：@(_WalterlvDemoCompile)" />
      </Target>
    
++    <!-- 引入 WPF 源码。 -->
++    <Target Name="_WalterlvDemoIncludeWpfFiles"
++            BeforeTargets="MarkupCompilePass1"
++            DependsOnTargets="_WalterlvDemoEvaluateProperties">
++      <ItemGroup>
++        <_WalterlvDemoPage Include="$(_WalterlvDemoSourceFolder)**\*.xaml" />
++        <Page Include="@(_WalterlvDemoPage)" Link="%(_WalterlvDemoPage.FileName).xaml" />
++      </ItemGroup>
++      <Message Text="2.2 引用 WPF 相关源码：@(_WalterlvDemoPage)" />
++    </Target>

++    <!-- 当生成 WPF 临时项目时，不会自动 Import NuGet 中的 props 和 targets 文件，这使得在临时项目中你现在看到的整个文件都不会参与编译。
++         然而，我们可以通过欺骗的方式在主项目中通过 _GeneratedCodeFiles 集合将需要编译的文件传递到临时项目中以间接参与编译。
++         WPF 临时项目不会 Import NuGet 中的 props 和 targets 可能是 WPF 的 Bug，也可能是刻意如此。
++         所以我们通过一个属性开关 `ShouldFixNuGetImportingBugForWpfProjects` 来决定是否修复这个错误。-->
++    <Target Name="_WalterlvDemoImportInWpfTempProject"
++            AfterTargets="MarkupCompilePass1"
++            BeforeTargets="GenerateTemporaryTargetAssembly"
++            DependsOnTargets="$(_WalterlvDemoImportInWpfTempProjectDependsOn)"
++            Condition=" '$(ShouldFixNuGetImportingBugForWpfProjects)' == 'True' ">
++      <ItemGroup>
++        <_GeneratedCodeFiles Include="@(_WalterlvDemoAllCompile)" />
++      </ItemGroup>
++      <Message Text="3. 正在欺骗临时项目，误以为此 NuGet 包中的文件是 XAML 编译后的中间代码：@(_WalterlvDemoAllCompile)" />
++    </Target>

    </Project>

我们增加了 _WalterlvDemoImportInWpfTempProjectDependsOn 属性，这个属性里面将填写一个到多个编译目标（Target）的名称（多个用分号分隔），用于告知 _WalterlvDemoImportInWpfTempProject 这个编译目标在执行之前必须确保执行的依赖编译目标。而我们目前的依赖目标只有一个，就是 _WalterlvDemoIncludeSourceFiles 这个引入 C# 源代码的编译目标。如果你有其他考虑有引入更多 C# 源代码的编译目标，则需要把他们都加上（当然本文是不需要的）。为此，我还新增了一个 _WalterlvDemoAllCompile 集合，如果存在多个依赖的编译目标会引入 C# 源代码，则需要像 _WalterlvDemoIncludeSourceFiles 一样，将他们都加入到 Compile 的同时也加入到 _WalterlvDemoAllCompile 集合中。

为什么可能有多个引入 C# 源代码的编译目标？因为本文我们只考虑了引入我们提前准备好的源代码放入源代码包中，而我们提到过可能涉及到动态生成 C# 源代码的需求。如果你有一两个编译目标会动态生成一些 C# 源代码并将其加入到 Compile 集合中，那么请将这个编译目标的名称加入到 _WalterlvDemoImportInWpfTempProjectDependsOn 属性（注意多个用分号分隔），同时将集合也引入一份到 _WalterlvDemoAllCompile 中。

_WalterlvDemoIncludeWpfFiles 这个编译目标的作用是引入 WPF 的 XAML 文件，这很容易理解，毕竟我们的源代码中包含 WPF 相关的文件。

请特别注意：

1. 我们加了一个 Link 属性，并且将其指定为 %(_WalterlvDemoPage.FileName).xaml。这意味着我们会把所有的 XAML 文件都当作在项目根目录中生成，如果你在其他的项目中用到了相对或绝对的 XAML 文件的路径，这显然会改变路径。但是，我们没有其他的方法来根据 XAML 文件所在的目录层级来自定指定 Link 属性让其在正确的层级上，所以这里才写死在根目录中。
   • 如果要解决这个问题，我们就需要在生成 NuGet 包之前生成此项目中所有 XAML 文件的正确的 Link 属性（例如改为 Views\%(_WalterlvDemoPage.FileName).xaml），这意味着需要在此项目编译期间执行一段代码，把 Package.targets 文件中为所有的 XAML 文件生成正确的 Link 属性。本文暂时不考虑这个问题，但你可以参考 dotnet-campus/SourceYard 项目来了解如何动态生成 Link。
2. 我们使用了 _WalterlvDemoPage 集合中转地存了 XAML 文件，这是必要的。因为这样才能正确通过 % 符号获取到 FileName 属性。

而 _WalterlvDemoImportInWpfTempProject 这个编译目标就不那么好理解了，而这个也是完美支持 WPF 项目源代码包的关键编译目标！这个编译目标指定在 MarkupCompilePass1 之后，GenerateTemporaryTargetAssembly 之前执行。GenerateTemporaryTargetAssembly 编译目标的作用是生成一个临时的项目，用于让 WPF 的 XAML 文件能够依赖同项目的 .NET 类型而编译。然而此临时项目编译期间是不会导入任何 NuGet 的 props 或 targets 文件的，这意味着我们特别添加的所有 C# 源代码在这个临时项目当中都是不存在的——如果项目使用到了我们源代码包中的源代码，那么必然因为类型不存在而无法编译通过——临时项目没有编译通过，那么整个项目也就无法编译通过。但是，我们通过在 MarkupCompilePass1 和 GenerateTemporaryTargetAssembly 之间将我们源代码包中的所有源代码加入到 _GeneratedCodeFiles 集合中，即可将这些文件加入到临时项目中一起编译。而原本 _GeneratedCodeFiles 集合中是什么呢？就是大家熟悉的 XAML 转换而成的 xxx.g.cs 文件。

测试和发布源代码包

现在我们再次编译这个项目，你将得到一个支持 WPF 项目的 NuGet 源代码包。

完整项目结构和源代码

至此，我们已经完成了编写一个 NuGet 源代码包所需的全部源码。接下来你可以在项目中添加更多的源代码，这样打出来的源代码包也将包含更多源代码。由于我们将将 XAML 文件都通过 Link 属性指定到根目录了，所以如果你需要添加 XAML 文件，你将只能添加到我们项目中的 Assets\src 目录下，除非做 dotnet-campus/SourceYard 中类似的动态 Link 生成的处理，或者在 Package.targets 文件中手工为每一个 XAML 编写一个特别的 Link 属性。

另外，在不改变我们整体项目结构的情况下，你也可以任意添加 WPF 所需的图片资源等。但也需要在 Package.targets 中添加额外的 Resource 引用。如果没有 dotnet-campus/SourceYard 的自动生成代码，你可能也需要手工编写 Resource。

接下来我会贴出更复杂的代码，用于处理更复杂的源代码包的场景。

目录结构

更复杂源代码包的项目组织形式会是下面这样图这样：

我们在 Assets 文件夹中新增了一个 assets 文件夹。由于资源在此项目中的路径必须和安装后的目标项目中一样才可以正确用 Uri 的方式使用资源，所以我们在项目文件 csproj 和编译文件 Package.targets 中都对这两个文件设置了 Link 到同一个文件夹中，这样才可以确保两边都能正常使用。

我们在 src 文件夹的不同子文件夹中创建了 XAML 文件。按照我们前面的说法，我们也需要像资源文件一样正确在 Package.targets 中设置 Link 才可以确保 Uri 是一致的。注意，我们接下来的源代码中没有在项目文件中设置 Link，原则上也是需要设置的，就像资源一样，这样才可以确保此项目和安装此 NuGet 包中的目标项目具有相同的 XAML Uri。此例子只是因为没有代码使用到了 XAML 文件的路径，所以才能得以幸免。

我们还利用了 tools 文件夹。我们在项目文件的末尾将输出文件拷贝到了 tools 目录下，这样，我们项目的 Assets 文件夹几乎与最终的 NuGet 包的文件夹结构一模一样，非常利于调试。但为了防止将生成的文件上传到版本管理，我在 tools 中添加了 .gitignore 文件：

/net*/*

项目文件

--  <Project Sdk="Microsoft.NET.Sdk">
++  <Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
    
      <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>net48</TargetFramework>
++      <UseWpf>True</UseWpf>
    
        <!-- 要求此项目编译时要生成一个 NuGet 包。-->
        <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
    
        <!-- 这里为了方便，我将 NuGet 包的输出路径设置在了解决方案根目录的 bin 文件夹下，而不是项目的 bin 文件夹下。-->
        <PackageOutputPath>..\bin\$(Configuration)</PackageOutputPath>
    
        <!-- 创建 NuGet 包时，项目的输出文件对应到 NuGet 包的 tools 文件夹，这可以避免目标项目引用我们的 NuGet 包的输出文件。
             同时，如果将来我们准备动态生成源代码，而不只是引入静态源代码，还可以有机会运行我们 Program 中的 Main 函数。-->
        <BuildOutputTargetFolder>tools</BuildOutputTargetFolder>
    
        <!-- 此包将不会传递依赖。意味着如果目标项目安装了此 NuGet 包，那么安装目标项目包的项目不会间接安装此 NuGet 包。-->
        <DevelopmentDependency>true</DevelopmentDependency>
    
        <!-- 包的版本号，我们设成了一个预览版；当然你也可以设置为正式版，即没有后面的 -alpha 后缀。-->
        <Version>0.1.0-alpha</Version>
    
        <!-- 设置包的作者。在上传到 nuget.org 之后，如果作者名与 nuget.org 上的账号名相同，其他人浏览包是可以直接点击链接看作者页面。-->
        <Authors>walterlv</Authors>
    
        <!-- 设置包的组织名称。我当然写成我所在的组织 dotnet 职业技术学院啦。-->
        <Company>dotnet-campus</Company>
      </PropertyGroup>
    
++    <!-- 我们添加的其他资源需要在这里 Link 到一个统一的目录下，以便在此项目和安装 NuGet 包的目标项目中可以用同样的 Uri 使用。 -->
++    <ItemGroup>
++      <Resource Include="Assets\assets\Icon.ico" Link="Assets\Icon.ico" Visible="False" />
++      <Resource Include="Assets\assets\Background.png" Link="Assets\Background.png" Visible="False" />
++    </ItemGroup>
      
      <!-- 在生成 NuGet 包之前，我们需要将我们项目中的文件夹结构一一映射到 NuGet 包中。-->
      <Target Name="IncludeAllDependencies" BeforeTargets="_GetPackageFiles">
        <ItemGroup>
    
          <!-- 将 Package.props / Package.targets 文件的名称在 NuGet 包中改为需要的真正名称。
               因为 NuGet 包要自动导入 props 和 targets 文件，要求文件的名称必须是 包名.props 和 包名.targets；
               然而为了避免我们改包名的时候还要同步改四个文件的名称，所以就在项目文件中动态生成。-->
          <None Include="Assets\build\Package.props" Pack="True" PackagePath="build\$(PackageId).props" />
          <None Include="Assets\build\Package.targets" Pack="True" PackagePath="build\$(PackageId).targets" />
          <None Include="Assets\buildMultiTargeting\Package.props" Pack="True" PackagePath="buildMultiTargeting\$(PackageId).props" />
          <None Include="Assets\buildMultiTargeting\Package.targets" Pack="True" PackagePath="buildMultiTargeting\$(PackageId).targets" />
    
          <!-- 我们将 src 目录中的所有源代码映射到 NuGet 包中的 src 目录中。-->
          <None Include="Assets\src\**" Pack="True" PackagePath="src" />

++        <!-- 我们将 assets 目录中的所有源代码映射到 NuGet 包中的 assets 目录中。-->
++        <None Include="Assets\assets\**" Pack="True" PackagePath="assets" />
    
        </ItemGroup>
      </Target>
    
++    <!-- 在编译结束后将生成的可执行程序放到 Tools 文件夹中，使得 Assets 文件夹的目录结构与 NuGet 包非常相似，便于 Sample 项目进行及时的 NuGet 包调试。 -->
++    <Target Name="_WalterlvDemoCopyOutputToDebuggableFolder" AfterTargets="AfterBuild">
++        <ItemGroup>
++        <_WalterlvDemoToCopiedFiles Include="$(OutputPath)**" />
++        </ItemGroup>
++        <Copy SourceFiles="@(_WalterlvDemoToCopiedFiles)" DestinationFolder="Assets\tools\$(TargetFramework)" />
++    </Target>

    </Project>

编译文件

    <Project>
    
      <PropertyGroup>
        <MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileFullPath)</MSBuildAllProjects>
      </PropertyGroup>
    
      <PropertyGroup>
        <!-- 我们增加了一个属性，用于处理 WPF 特殊项目的源代码之前，确保我们已经收集到所有需要引入的源代码。 -->
        <_WalterlvDemoImportInWpfTempProjectDependsOn>_WalterlvDemoIncludeSourceFiles</_WalterlvDemoImportInWpfTempProjectDependsOn>
      </PropertyGroup>
      
      <Target Name="_WalterlvDemoEvaluateProperties">
        <PropertyGroup>
          <_WalterlvDemoRoot>$(MSBuildThisFileDirectory)..\</_WalterlvDemoRoot>
          <_WalterlvDemoSourceFolder>$(MSBuildThisFileDirectory)..\src\</_WalterlvDemoSourceFolder>
        </PropertyGroup>
        <Message Text="1. 初始化源代码包的编译属性" />
      </Target>
    
      <!-- 引入主要的 C# 源码。 -->
      <Target Name="_WalterlvDemoIncludeSourceFiles"
              BeforeTargets="CoreCompile"
              DependsOnTargets="_WalterlvDemoEvaluateProperties">
        <ItemGroup>
          <_WalterlvDemoCompile Include="$(_WalterlvDemoSourceFolder)**\*.cs" />
          <_WalterlvDemoAllCompile Include="@(_WalterlvDemoCompile)" />
          <Compile Include="@(_WalterlvDemoCompile)" />
        </ItemGroup>
        <Message Text="2.1 引入源代码包中的所有源代码：@(_WalterlvDemoCompile)" />
      </Target>
    
      <!-- 引入 WPF 源码。 -->
      <Target Name="_WalterlvDemoIncludeWpfFiles"
              BeforeTargets="MarkupCompilePass1"
              DependsOnTargets="_WalterlvDemoEvaluateProperties">
        <ItemGroup>
--        <_WalterlvDemoPage Include="$(_WalterlvDemoSourceFolder)**\*.xaml" />
--        <Page Include="@(_WalterlvDemoPage)" Link="Views\%(_WalterlvDemoPage.FileName).xaml" />
++        <_WalterlvDemoRootPage Include="$(_WalterlvDemoSourceFolder)FooView.xaml" />
++        <Page Include="@(_WalterlvDemoRootPage)" Link="Views\%(_WalterlvDemoRootPage.FileName).xaml" />
++        <_WalterlvDemoThemesPage Include="$(_WalterlvDemoSourceFolder)Themes\Walterlv.Windows.xaml" />
++        <Page Include="@(_WalterlvDemoThemesPage)" Link="Views\%(_WalterlvDemoThemesPage.FileName).xaml" />
++        <_WalterlvDemoIcoResource Include="$(_WalterlvDemoRoot)assets\*.ico" />
++        <_WalterlvDemoPngResource Include="$(_WalterlvDemoRoot)assets\*.png" />
++        <Resource Include="@(_WalterlvDemoIcoResource)" Link="assets\%(_WalterlvDemoIcoResource.FileName).ico" />
++        <Resource Include="@(_WalterlvDemoPngResource)" Link="assets\%(_WalterlvDemoPngResource.FileName).png" />
        </ItemGroup>
--      <Message Text="2.2 引用 WPF 相关源码：@(_WalterlvDemoPage);@(_WalterlvDemoIcoResource);@(_WalterlvDemoPngResource)" />
++      <Message Text="2.2 引用 WPF 相关源码：@(_WalterlvDemoRootPage);@(_WalterlvDemoThemesPage);@(_WalterlvDemoIcoResource);@(_WalterlvDemoPngResource)" />
      </Target>
    
      <!-- 当生成 WPF 临时项目时，不会自动 Import NuGet 中的 props 和 targets 文件，这使得在临时项目中你现在看到的整个文件都不会参与编译。
           然而，我们可以通过欺骗的方式在主项目中通过 _GeneratedCodeFiles 集合将需要编译的文件传递到临时项目中以间接参与编译。
           WPF 临时项目不会 Import NuGet 中的 props 和 targets 可能是 WPF 的 Bug，也可能是刻意如此。
           所以我们通过一个属性开关 `ShouldFixNuGetImportingBugForWpfProjects` 来决定是否修复这个错误。-->
      <Target Name="_WalterlvDemoImportInWpfTempProject"
              AfterTargets="MarkupCompilePass1"
              BeforeTargets="GenerateTemporaryTargetAssembly"
              DependsOnTargets="$(_WalterlvDemoImportInWpfTempProjectDependsOn)"
              Condition=" '$(ShouldFixNuGetImportingBugForWpfProjects)' == 'True' ">
        <ItemGroup>
          <_GeneratedCodeFiles Include="@(_WalterlvDemoAllCompile)" />
        </ItemGroup>
        <Message Text="3. 正在欺骗临时项目，误以为此 NuGet 包中的文件是 XAML 编译后的中间代码：@(_WalterlvDemoAllCompile)" />
      </Target>
    
    </Project>

开源项目

本文涉及到的所有代码均已开源到：

• walterlv.demo/Walterlv.PackageDemo at master · walterlv/walterlv.demo

更多内容

SourceYard 开源项目

本文服务于开源项目 SourceYard，为其提供支持 WPF 项目的解决方案。dotnet-campus/SourceYard: Add a NuGet package only for dll reference? By using dotnetCampus.SourceYard, you can pack a NuGet package with source code. By installing the new source code package, all source codes behaviors just like it is in your project.

相关博客

更多制作源代码包的博客可以阅读。从简单到复杂的顺序：

• 将 .NET Core 项目打一个最简单的 NuGet 源码包，安装此包就像直接把源码放进项目一样 - 吕毅
• Roslyn 如何基于 Microsoft.NET.Sdk 制作源代码包 - 林德熙
• 制作通过 NuGet 分发的源代码包时，如果目标项目是 WPF 则会出现一些问题（探索篇，含解决方案） - 吕毅
• SourceYard 制作源代码包 - 林德熙

WPF 程序的编译过程

基于 Sdk 的项目进行编译的时候，会使用 Sdk 中附带的 props 文件和 targets 文件对项目进行编译。Microsoft.NET.Sdk.WindowsDesktop 的 Sdk 包含 WPF 项目的编译过程。

而本文介绍 WPF 项目的编译过程，包含 WPF 额外为编译过程添加的那些扩展编译目标，以及这些扩展的编译目标如何一步步完成 WPF 项目的过程。

提前准备

在阅读本文之前，你可能需要提前了解编译过程到底是怎样的。可以阅读：

• 理解 C# 项目 csproj 文件格式的本质和编译流程

如果你不明白上面文章中的一些术语（例如 Target / Task），可能不能理解本文后面的内容。

另外，除了本文所涉及的内容之外，你也可以自己探索编译过程：

• 解读 Microsoft.NET.Sdk 的源码，你能定制各种奇怪而富有创意的编译过程

WPF 的编译代码都在 Microsoft.WinFx.targets 文件中，你可以通过上面这一篇博客找到这个文件。接下来，我们会一一介绍这个文件里面的编译目标（Target），然后统一说明这些 Target 是如何协同工作，将 WPF 程序编译出来的。

Microsoft.WinFx.targets 的源码可以查看：

• wpf/Microsoft.WinFx.targets at master · dotnet/wpf

Target

WPF 在编译期间会执行以下这些 Target，当然 Target 里面实际用于执行任务的是 Task。

知道 Target 名称的话，你可以扩展 WPF 的编译过程；而知道 Task 名称的话，可以帮助理解编译过程实际做的事情。

本文都会列举出来。

FileClassification

• Target 名称：FileClassification
• Task 名称：FileClassifier

用于将资源嵌入到程序集。如果资源没有本地化，则嵌入到主程序集；如果有本地化，则嵌入到附属程序集。

在 WPF 项目中，这个 Target 是一定会执行的；但里面的 Task 则是有 Resource 类型的编译项的时候才会执行。

GenerateTemporaryTargetAssembly

Target 名称和 Task 名称相同，都是 GenerateTemporaryTargetAssembly。

只要项目当中包含任何一个生成类型为 Page 的 XAML 文件，则会执行此 Target。

关于生成临时程序集的原因比较复杂，可以阅读本文后面的 WPF 程序的编译过程部分来了解。

MarkupCompilePass1

Target 名称和 Task 名称相同，都是 MarkupCompilePass1。

将非本地化的 XAML 文件编译成二进制格式。

MarkupCompilePass2

Target 名称和 Task 名称相同，都是 MarkupCompilePass2。

对 XAML 文件进行第二轮编译，而这一次会引用同一个程序集中的类型。

DesignTimeMarkupCompilation

这是一个仅在有设计器执行时才会执行的 Target，当这个编译目标执行时，将会直接调用 MarkupCompilePass1。

实际上，如果在 Visual Studio 中编译项目，则会调用到这个 Target。而判断是否在 Visual Studio 中编译的方法可以参见：

• MSBuild 在编写编译任务的时候判断当前是否在 Visual Studio 中编译

<Target Name="DesignTimeMarkupCompilation">

    <!-- Only if we are not actually performing a compile i.e. we are in design mode -->
    <CallTarget Condition="'$(BuildingProject)' != 'true'"
                Targets="MarkupCompilePass1" />
</Target>

MergeLocalizationDirectives

Target 名称和 Task 名称相同，都是 MergeLocalizationDirectives。

将本地化属性和一个或多个 XAML 二进制格式文件的注释合并到整个程序集的单一文件中。

<Target Name="MergeLocalizationDirectives"
        Condition="'@(GeneratedLocalizationFiles)' !=''"
        Inputs="@(GeneratedLocalizationFiles)"
        Outputs="$(IntermediateOutputPath)$(AssemblyName).loc"
>
    <MergeLocalizationDirectives GeneratedLocalizationFiles="@(GeneratedLocalizationFiles)"
                                OutputFile="$(IntermediateOutputPath)$(AssemblyName).loc"/>

    <!--
        Add the merged loc file into _NoneWithTargetPath so that it will be copied to the
        output directory
    -->
    <CreateItem Condition="Exists('$(IntermediateOutputPath)$(AssemblyName).loc')"
                Include="$(IntermediateOutputPath)$(AssemblyName).loc"
                AdditionalMetadata="CopyToOutputDirectory=PreserveNewest; TargetPath=$(AssemblyName).loc" >
        <Output ItemName="_NoneWithTargetPath" TaskParameter="Include"/>
        <Output ItemName="FileWrites" TaskParameter="Include"/>

    </CreateItem>

</Target>

MainResourcesGeneration、SatelliteResourceGeneration

• Target 有两个，MainResourcesGeneration 和 SatelliteResourceGeneration，分别负责主资源生成和附属资源生成。
• Task 名称：ResourcesGenerator

将一个或多个资源（二进制格式的 .jpg、.ico、.bmp、XAML 以及其他扩展名类型）嵌入 .resources 文件中。

CheckUid、UpdateUid、RemoveUid

• Target 有三个，CheckUid、UpdateUid 和 RemoveUid，分别负责主资源生成和附属资源生成。
• Task 名称：ResourcesGenerator

检查、更新或移除 UID，以便将 XAML 文件中所有的 XAML 元素进行本地化。

<Target Name="CheckUid"
        Condition="'@(Page)' != '' or '@(ApplicationDefinition)' != ''">

    <UidManager MarkupFiles="@(Page);@(ApplicationDefinition)" Task="Check" />

</Target>

<Target Name="UpdateUid"
        Condition="'@(Page)' != '' or '@(ApplicationDefinition)' != ''">

    <UidManager MarkupFiles="@(Page);
                            @(ApplicationDefinition)"
                IntermediateDirectory ="$(IntermediateOutputPath)"
                Task="Update" />

</Target>

<Target Name="RemoveUid"
        Condition="'@(Page)' != '' or '@(ApplicationDefinition)' != ''">
    <UidManager MarkupFiles="@(Page);
                            @(ApplicationDefinition)"

                IntermediateDirectory ="$(IntermediateOutputPath)"
                Task="Remove" />

</Target>

UpdateManifestForBrowserApplication

当编译基于 XAML 的浏览器项目的时候，会给 manifest 文件中添加一个配置 <hostInBrowser />。

WPF 程序的编译过程

编译过程图示

上面列举出来的那些 Target 主要是 WPF 几个关键的 Target，在实际编译时会有更多编译 Target 执行。另外有些也不在常规的编译过程中，而是被专门的编译过程执行。

图的阅读方法是这样的：

1. 箭头代表依赖关系，如 CoreCompile 有一个指向 DesignTimeMarkupCompilation 的箭头，表示 CoreCompile 执行前会确保 DesignTimeMarkupCompilation 执行完毕；
2. 如果一个 Target 有多个依赖，则这些依赖会按顺序执行还没执行的依赖，如 PrepareResources 指向了多个 Target MarkupCompilePass1、GenerateTemporaryTargetAssembly、MarkupCompilePass2、AfterMarkupCompilePass2、CleanupTemporaryTargetAssembly，那么在 PrepareResources 执行之前，如果还有没有执行的依赖，会按顺序依次执行；
3. WPF 所有的 Target 扩展都是通过依赖来指定的，也就是说必须基于现有的核心编译过程，图中从绿色或黄色的节点向前倒退的所有依赖都会被执行。

各种颜色代表的含义：

• 蓝色，表示 WPF 扩展的 Target
• 浅蓝色，表示 WPF 扩展的 Target，但是没有执行任何实际的任务，只是提供一个扩展点
• 绿色，表示核心的编译过程，但是被 WPF 编译过程重写了
• 黄色，表示核心的编译过程（即便不是 WPF 程序也会执行的 Target）
• 浅黄色，表示在这张图里面不关心的 Target（不然整个画下来就太多了）
• 紫色，仅在 Visual Studio 编译期间会执行的 WPF 扩展的 Target

编译过程描述

我们都知道 XAML 是可以引用 CLR 类型的；如果 XAML 所引用的 CLR 类型在其他被引用的程序集，那么编译 XAML 的时候就可以直接引用这些程序集，因为他们已经编译好了。

但是我们也知道，XAML 还能引用同一个程序集中的 CLR 类型，而此时这个程序集还没有编译，XAML 编译过程并不知道可以如何使用这些类型。同时我们也知道 CLR 类型可是使用 XAML 生成的类型，如果 XAML 没有编译，那么 CLR 类型也无法正常完成编译。这是矛盾的，这也是 WPF 扩展的编译过程会比较复杂的原因之一。

WPF 编译过程有两个编译传递，MarkupCompilePass1 和 MarkupCompilePass2。

MarkupCompilePass1 的作用是将 XAML 编译成二进制格式。如果 XAML 文件包含 x:Class 属性，那么就会根据语言生成一份代码文件；对于 C# 语言，会生成“文件名.g.cs”文件。但是 XAML 文件中也有可能包含对同一个程序集中的 CLR 类型的引用，然而这一编译阶段 CLR 类型还没有开始编译，因此无法提供程序集引用。所以如果这个 XAML 文件包含对同一个程序集中 CLR 类型的引用，则这个编译会被推迟到 MarkupCompilePass2 中继续。而在 MarkupCompilePass1 和 MarkupCompilePass2 之间，则插入了 GenerateTemporaryTargetAssembly 这个编译目标。

GenerateTemporaryTargetAssembly 的作用是生成一个临时的程序集，这个临时的程序集中包含了 MarkupCompilePass1 推迟到 MarkupCompilePass2 中编译时需要的 CLR 类型。这样，在 MarkupCompilePass2 执行的时候，会获得一个包含原本在统一程序集的 CLR 类型的临时程序集引用，这样就可以继续完成 XAML 格式的编译了。在 MarkupCompilePass2 编译完成之后，XAML 文件就完全编译完成了。之后，会执行 CleanupTemporaryTargetAssembly 清除之前临时编译的程序集。

编译临时程序集时，会生成一个新的项目文件，名字如：$(项目名)_$(随机字符)_wpftmp.csproj，在与原项目相同的目录下。

在需要编译一个临时程序集的时候，CoreCompile 这样的用于编译 C# 代码文件的编译目标会执行两次，第一次是编译这个临时生成的项目，而第二次才是编译原本的项目。

现在，我们看一段 WPF 程序的编译输出，可以看到看到这个生成临时程序集的过程。

随后，就是正常的其他的编译过程。

关于临时生成程序集

在 WPF 的编译过程中，我想单独将临时生成程序集的部分进行特别说明。因为如果你不了解这一部分的细节，可能在未来的使用中遇到一些临时生成程序集相关的坑。

下面这几篇博客就是在讨论其中的一些坑：

• 制作通过 NuGet 分发的源代码包时，如果目标项目是 WPF 则会出现一些问题
• Roslyn 如何基于 Microsoft.NET.Sdk 制作源代码包

我需要摘抄生成临时程序集的一部分源码：

<PropertyGroup>
    <_CompileTargetNameForLocalType Condition="'$(_CompileTargetNameForLocalType)' == ''">_CompileTemporaryAssembly</_CompileTargetNameForLocalType>
</PropertyGroup>

<Target Name="_CompileTemporaryAssembly"  DependsOnTargets="BuildOnlySettings;ResolveKeySource;CoreCompile" />

<Target Name="GenerateTemporaryTargetAssembly"
        Condition="'$(_RequireMCPass2ForMainAssembly)' == 'true' " >

    <Message Text="MSBuildProjectFile is $(MSBuildProjectFile)" Condition="'$(MSBuildTargetsVerbose)' == 'true'" />

    <GenerateTemporaryTargetAssembly
            CurrentProject="$(MSBuildProjectFullPath)"
            MSBuildBinPath="$(MSBuildBinPath)"
            ReferencePathTypeName="ReferencePath"
            CompileTypeName="Compile"
            GeneratedCodeFiles="@(_GeneratedCodeFiles)"
            ReferencePath="@(ReferencePath)"
            IntermediateOutputPath="$(IntermediateOutputPath)"
            AssemblyName="$(AssemblyName)"
            CompileTargetName="$(_CompileTargetNameForLocalType)"
            GenerateTemporaryTargetAssemblyDebuggingInformation="$(GenerateTemporaryTargetAssemblyDebuggingInformation)"
            >

    </GenerateTemporaryTargetAssembly>

    <CreateItem Include="$(IntermediateOutputPath)$(TargetFileName)" >
        <Output TaskParameter="Include" ItemName="AssemblyForLocalTypeReference" />
    </CreateItem>

</Target>

我们需要关注这些点：

1. 生成临时程序集时，会调用一个编译目标（Target），这个编译目标的名称由 _CompileTargetNameForLocalType 这个私有属性来决定；
2. 当 _CompileTargetNameForLocalType 没有指定时，会设置其默认值为 _CompileTemporaryAssembly 这个编译目标；
3. _CompileTemporaryAssembly 这个编译目标执行时，仅会执行三个依赖的编译目标，BuildOnlySettings、ResolveKeySource、CoreCompile，至于这些依赖目标所依赖的其他编译目标，则会根据新生成的项目文件动态计算。
4. 生成临时程序集和临时程序集的编译过程并不在同一个编译上下文中，这也是为什么只能通过传递名称 _CompileTargetNameForLocalType 来执行，而不能直接调用这个编译目标或者设置编译目标的依赖。

新生成的临时项目文件相比于原来的项目文件，包含了这些修改：

1. 添加了第一轮 XAML 编译传递（MarkupCompilePass1）时生成的 .g.cs 文件；
2. 将所有引用方式收集到的引用全部换成 ReferencePath，这样就可以避免临时项目编译期间再执行一次 ResolveAssemblyReference 编译目标来收集引用，避免降低太多性能。

关于引用换成 ReferencePath 的内容，可以阅读我的另一篇博客了解更多：

• 在 Target 中获取项目引用的所有依赖（dll/NuGet/Project）的路径

在使用 ReferencePath 的情况下，无论是项目引用还是 NuGet 包引用，都会被换成普通的 dll 引用，因为这个时候目标项目都已经编译完成，包含可以被引用的程序集。

以下是我在示例程序中抓取到的临时生成的项目文件的内容，与原始项目文件之间的差异：

    <Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
        <PropertyGroup>
            <OutputType>Exe</OutputType>
            <TargetFramework>net48</TargetFramework>
            <UseWPF>true</UseWPF>
            <GenerateTemporaryTargetAssemblyDebuggingInformation>True</GenerateTemporaryTargetAssemblyDebuggingInformation>
        </PropertyGroup>
        <ItemGroup>
            <PackageReference Include="Walterlv.SourceYard.Demo" Version="0.1.0-alpha" />
        </ItemGroup>
++      <ItemGroup>
++          <ReferencePath Include="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\mscorlib.dll" />
++          <ReferencePath Include="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\PresentationCore.dll" />
++          <ReferencePath Include="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\PresentationFramework.dll" />
++          <ReferencePath Include="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\System.Core.dll" />
++          <ReferencePath Include="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\System.Data.dll" />
++          <ReferencePath Include="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\System.dll" />
++          <ReferencePath Include="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\System.Drawing.dll" />
++          <ReferencePath Include="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\System.IO.Compression.FileSystem.dll" />
++          <ReferencePath Include="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\System.Numerics.dll" />
++          <ReferencePath Include="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\System.Runtime.Serialization.dll" />
++          <ReferencePath Include="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\System.Windows.Controls.Ribbon.dll" />
++          <ReferencePath Include="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\System.Xaml.dll" />
++          <ReferencePath Include="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\System.Xml.dll" />
++          <ReferencePath Include="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\System.Xml.Linq.dll" />
++          <ReferencePath Include="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\UIAutomationClient.dll" />
++          <ReferencePath Include="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\UIAutomationClientsideProviders.dll" />
++          <ReferencePath Include="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\UIAutomationProvider.dll" />
++          <ReferencePath Include="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\UIAutomationTypes.dll" />
++          <ReferencePath Include="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\WindowsBase.dll" />
++      </ItemGroup>
++      <ItemGroup>
++          <Compile Include="D:\Developments\Open\Walterlv.Demo\Walterlv.GettingStarted.SourceYard\Walterlv.GettingStarted.SourceYard.Sample\obj\Debug\net48\Demo.g.cs" />
++      </ItemGroup>
    </Project>