按类别查找文章：C#

推荐 .NET/C# 开发者安装的几款代码分析插件或对应的代码分析 NuGet 包

如果你使用的是旧版本的 Visual Studio，那么默认的代码分析规则集是“最小建议规则集”。基于这个，写出来的代码其实只能说是能跑通过而已。随着 Roslyn 的发布，带来了越来越多更强大的代码分析器，可以为编写高质量的代码带来更多的帮助。

作为 .NET/C# 开发者，强烈建议安装本文推荐的几款代码分析器。

推荐

1. Visual Studio 2019 自带的分析器
2. Microsoft Code Analysis
   • VS 扩展：Microsoft Code Analysis 2019
   • NuGet 包： Microsoft.CodeAnalysis.FxCopAnalyzers
3. Roslynator
   • VS 扩展：Roslynator 2019
   • VS Code 扩展：Roslynator
   • NuGet 包：Roslynator.Analyzers
4. Code Cracker
   • VS 扩展：Code Cracker for C#
   • NuGet 包：codecracker.CSharp
5. Meziantou.Analyzer
   • VS 扩展：Meziantou.Analyzer
   • NuGet 包：Meziantou.Analyzer

类型

这里的分析器分为 Visual Studio 扩展形式的分析器和 NuGet 包形式的分析器。

Visual Studio 扩展形式的分析器可以让你一次安装对所有项目生效，但缺点是不能影响编译过程，只能作为在 Visual Studio 中编写代码时给出提示。

NuGet 包形式的分析器可以让某个项目中的所有成员享受到同样的代码分析提示（无论是否安装插件），但缺点是仅针对单个项目生效。

简介

Visual Studio 2019 自带的分析器

上图生效的分析器就是 Visual Studio 2019 自带的分析器。在可能有问题的代码上，Visual Studio 的代码编辑器会显示一些文字效果来提醒你代码问题。比如这张图就是提示私有成员 Foo 未使用。

Visual Studio 2019 自带的分析器的诊断 ID 都是以 IDE 开头，因此你可以通过这个前缀来区分是否是 Visual Studio 2019 自带的分析器提示的。

另外，自带的分析器可谓非常强大，除了以上这种提示之外，还可以提示一些重复代码的修改。比如你修改了某段代码，它会提示你相似的代码也可能需要修改。

Microsoft Code Analysis

Microsoft Code Analysis 分为两种用法，一个是 Visual Studio 扩展的形式，你可以去这里下载安装或者去 Visual Studio 的扩展管理界面搜索安装；另一个是 NuGet 包的形式，你可以直接在项目的 NuGet 管理界面安装 Microsoft.CodeAnalysis.FxCopAnalyzers。

这款分析器也是微软主推的代码分析器，可以分析 API 设计问题、全球化与本地化问题、稳定性问题、性能问题、安全性问题、代码使用问题等非常多的种类。

比如下图是稳定性的一个问题，直接 catch 了一个 Exception 基类：

虽然你可以通过配置规则严重性来消除提示，但是这样写通常代码也比较容易出现一些诡异的问题而难以定位。

Microsoft Code Analysis 分析器的诊断 ID 都是以 CA 开头，因此你可以通过这个前缀来区分是否是 Microsoft Code Analysis 分析器提示的。

Microsoft.CodeAnalysis.FxCopAnalyzers 的 NuGet 包实际上是一组分析器的合集，包括：

• Microsoft.CodeAnalysis.FxCopAnalyzers
  • 主分析器，分析各种代码问题
• Microsoft.CodeQuality.Analyzers
  • 专门分析代码质量的分析器（比如没有使用某个参数）
• Microsoft.NetCore.Analyzers
  • 如果你在使用 .NET Core 或者 .NET Standard，那么此分析器会告诉你更恰当地使用框架提供的 API（如果 API 恰好与 .NET Framework 桌面应用相同，那么 .NET Framework 桌面应用也因此受益）
• Microsoft.NetFramework.Analyzers
  • 如果你在使用 .NET Framework 开发桌面应用，那么此分析器会告诉你更恰当地使用框架提供的 API

如果你想安装这款 NuGet 包，并不需要特别去 NuGet 包管理器中安装，也不需要命令行，只需要去项目的属性页面，选择“安装”就好了。如下图：

Roslynator

是第三方开发者开发的，代码已在 GitHub 上开源，社区非常活跃：

• JosefPihrt/Roslynator: A collection of 500+ analyzers, refactorings and fixes for C#, powered by Roslyn.

提供了 500 多个代码分析和重构。更值得推荐的一个原因是他为 Visual Studio 原本的很多报告了问题的代码提供了生成解决问题代码的能力。

Code Cracker

Code Cracker 是第三方开发者开发的，代码已在 GitHub 上开源：

• code-cracker/code-cracker: An analyzer library for C# and VB that uses Roslyn to produce refactorings, code analysis, and other niceties.

由于这款分析器的出现比 Visual Studio 2019 早很多，所以待 Visual Studio 2019 出现的时候，他们已经出现了一些规则的重复（意味着你可能同一个问题会被 Visual Studio 报一次，又被 Code Cracker 报一次）。

虽然部分重复，但 Code Cracker 依然提供了很多 Visual Studio 2019 和 Microsoft Code Analysis 都没有带的代码质量提示。

比如，如果你代码中的文档注释缺少了某个参数的注释，那么它会给出提示：

Code Cracker 支持的所有种类的代码分析都可以在这里查得到：

• All diagnostics - Code Cracker

Meziantou.Analyzer

这款插件是对其他几款分析器的重要补充。如果说其他几款分析器可以帮你解决一些基本设计问题或者 Bug 的话，这款分析器可以帮你发现更大范围的问题。

最典型的，也是我推荐这款分析器的最大原因是 —— 区域和本地化！

你的每一个 ToString()，每一个字符串比较，每一个字典的构造……他都提醒你需要考虑区域问题，然后提供给你区域问题的推荐代码！

配置代码分析严重程度

你的项目中对于某项规则严重性的看法也许跟微软或其他第三方分析器不一样，因此你需要自己配置规则集的严重性。

关于如何配置代码分析严重程度，你可以阅读：

• 使用 .editorconfig 配置 .NET/C# 项目的规则严重性 - walterlv

dotnet 使用 Qpush 快速从电脑到手机推送文字

在手机打字总不是方便，于是就有了 Qpush 这个工具，通过这个工具可以快速从电脑到手机推送文字。 但是这个工具没有找到客户端，于是我就给他写了一个库，通过这个库可以快速进行开发

.NET 将多个程序集合并成单一程序集的 4+3 种方法

编写 .NET 程序的时候，我们经常会在项目的输出目录下发现一大堆的文件。除了我们项目自己生成的程序集之外，还能找到这个项目所依赖的一大堆依赖程序集。有没有什么方法可以把这些依赖和我们的程序集合并到一起呢？

本文介绍四种将程序集和依赖打包合并到一起的方法，每一种方法都有其不同的原理和优缺点。我将介绍这些方法的原理并帮助你决定哪种方法最适合你想要使用的场景。

四种方法

目前我已知的将 .NET 程序集与依赖合并到一起的方法有下面四种：

1. 使用 .NET Core 3.0 自带的 PublishSingleFile 属性合并依赖
2. 使用 Fody
3. 使用 SourceYard 源代码包
4. 使用 ILMerge（微软所写）或者 ILRepack（基于 Mono.Ceil）
5. 其他方法

如果你还知道有其他的方法，欢迎评论指出，非常感谢！

上面的第五种方法我也会做一些介绍，要么是因为无法真正完成任务或者适用场景非常有限，要么是其原理我还不理解，因此只进行简单介绍。

使用 .NET Core 3.0 自带的 PublishSingleFile 属性合并依赖

.NET Core 3.0 自 Preview 5 开始，增加了发布成单一 exe 文件的功能。

在你的项目文件中增加下面的两行可以开启此功能：

    <Project Sdk="Microsoft.NET.Sdk">
    
      <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>netcoreapp3.0</TargetFramework>
++      <RuntimeIdentifier>win10-x64</RuntimeIdentifier>
++      <PublishSingleFile>true</PublishSingleFile>
      </PropertyGroup>
    
    </Project>

第一行 RuntimeIdentifier 一定需要指定，因为发布的单一文件是特定于架构的。这里，我们指定了 win10-x64，你也可以指定为其他的值。可以使用的值你可以在这篇文章中查询到：

• .NET Core Runtime IDentifier (RID) catalog - Microsoft Docs

第二行 PublishSingleFile 即开启发布时单一文件的功能。这样，你在发布你的程序的时候可以得到一个单一的可执行程序。发布一个 .NET Core 项目的方法是在命令行中输入：

dotnet publish

当然，如果你没有更改任何你的项目文件（没有增加上面的那两行），那么你在使用发布命令的时候就需要把这两个属性再增加上。因此完整的发布命令是下面这样的：

dotnet publish -r win10-x64 /p:PublishSingleFile=true

这里的 -r 就等同于在项目中指定 RuntimeIdentifier 持续。这里的 /p 是在项目中增加一个属性，而增加的属性名是 PublishSingleFile，增加的属性值是 true。

使用 .NET Core 3.0 这种自带的发布单一 exe 的方法会将你的程序的全部文件（包括所有依赖文件，包括非托管程序集，包括各种资源文件）全部打包到一个 exe 中。当运行这个 exe 的时候，会首先将所有这些文件生成到本地计算机中一个临时目录下。只有第一次运行这个 exe 的时候才会生成这个目录和其中的文件，之后的运行是不会再次生成的。

下面说一些 .NET Core 3.0 发布程序集的一点扩展——.NET Core 3.0 中对于发布程序集的三种处理方式可以放在一起使用：

• 裁剪程序集（Assembly Trimmer）
• 提前编译（Ahead-of-Time compilation，通过 crossgen）后面马上会说到 Microsoft.DotNet.ILCompiler
• 单一文件打包（Single File Bundling）本小节

关于 .NET Core 3.0 中发布仅一个 exe 的方法、原理和实践，可以参见林德熙的博客：

• dotnet core 发布只有一个 exe 的方法

.NET Core 在 GitHub 上开源：

• .NET Foundation

使用 Fody

在你的项目中安装一个 NuGet 包 Costura.Fody。一般来说，安装完之后，你编译的时候就会生成仅有一个 exe 的程序集了。

如果你继续留意，可以发现项目中多了一个 Fody 的专属配置文件 FodyWeavers.xml，内容如下：

<?xml version="1.0" encoding="utf-8" ?>
<Weavers>
    <Costura/>
</Weavers>

仅仅到此为止你已经足够利用 Fody 完成程序集的合并了。

但是，如果希望对 Fody 进行更精细化的配置，可以阅读叶洪的博客：

• .NET 合并程序集（将 dll 合并到 exe 中） - Iron 的博客 - CSDN博客

Fody 在 GitHub 上开源：

• Fody/Fody: Extensible tool for weaving .net assemblies

使用 SourceYard 源代码包

SourceYard 源代码包在程序集合并上是另辟蹊径的一种合并方式。它不能帮助你将所有的依赖全部合并，但足以让你在发布一些简单应用的时候不至于引入大量的依赖。

例如，你可以考虑新建一个项目，然后安装下面的 NuGet 包：

• lindexi.src.MacAddress.Source

安装完成之后，你就可以在你的项目中使用到此 NuGet 包为你带来的获取 MAC 地址的工具类了。

using System;
using lindexi.src;

namespace Walterlv.Demo
{
    internal static class Program
    {
        static void Main()
        {
            var macList = MacAddress.GetActiveMacAddress();
            foreach (var mac in macList)
            {
                Console.WriteLine(mac);
            }
        }
    }
}

编译完你的项目，你会发现你的项目没有携带任何依赖。你安装的 NuGet 包并没有成为你的依赖，反而成为你正在编译的程序集的一部分。

如果你要制作一个像上面那样的源代码包，只需要在你要制作 NuGet 包的项目安装上 dotnetCampus.SourceYard，在你打包成 NuGet 包的时候，就会生成一个普通的 NuGet 包以及一个 *.Source.nupkg 的源代码包。将源代码包上传到 nuget.org 上，其他人便可以安装你制作的源代码包了。

关于如何使用 SourceYard 制作一个源代码包的方法可以阅读林德熙的博客：

• SourceYard 制作源代码包

关于能够做出源代码包的原理，可以阅读我的博客：

• 入门篇：将 .NET Core 项目打一个最简单的 NuGet 源码包，安装此包就像直接把源码放进项目一样
• 进阶篇：从零开始制作 NuGet 源代码包（全面支持 .NET Core / .NET Framework / WPF 项目）

SourceYard 在 GitHub 上开源：

• 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.

使用 ILMerge 或者 ILRepack 等工具

ILMerge 和 ILRepack 的合并就更加富有技术含量——当然坑也更多。

这两个都是工具，因此，你需要将工具下载下来使用。你有很多种方法下载到工具使用，因此我会推荐不同的人群使用不同的工具。

ILMerge

ILMerge 命令行工具是微软官方出品，下载地址：

• Download ILMerge from Official Microsoft Download Center

其使用方法请参见我的博客：

• .NET 使用 ILMerge 合并多个程序集，避免引入额外的依赖 - walterlv

ILRepack

ILRepack 基于 Mono.Ceil 来进行 IL 合并，其使用方法可以参见我的博客：

• .NET 使用 ILRepack 合并多个程序集（替代 ILMerge），避免引入额外的依赖 - walterlv

ILMerge-GUI 工具（已过时，但适合新手随便玩玩）

你可以在以下网址中找到 ILMerge-GUI 的下载链接：

• wvd-vegt / ilmergegui / Downloads — Bitbucket

ILMerge-GUI 工具在 Bitbucket 上开源：

• wvd-vegt / ilmergegui — Bitbucket

其他方法

使用 Microsoft.DotNet.ILCompiler

可以将 .NET Core 编译为单个无依赖的 Native 程序。

你需要先安装一个预览版的 NuGet 包 Microsoft.DotNet.ILCompiler

关于 Microsoft.DotNet.ILCompiler 的使用，你可以阅读林德熙的博客：

• dotnet core 使用 CoreRT 将程序编译为 Native 程序

使用 dnSpy

dnSpy 支持添加一个模块到程序集，也可以创建模块，还可以将程序集转换为模块。因此，一个程序集可以包含多个模块的功能就可以被充分利用起来。

使用 Warp

Warp 在 GitHub 上开源：

• dgiagio/warp: Create self-contained single binary applications

其使用可以参见林德熙的博客：

• dotnet core 发布只有一个 exe 的方法

各种方法的原理和使用场景比较

原理

使用 .NET Core 3.0 自带的 PublishSingleFile 属性合并依赖，其原理是生成一个启动器容器程序。最终没有对程序进行任何修改，只是单纯的打包而已。

使用 Fody，是将程序集依赖放到了资源里面。当要加载程序集的时候，会直接将资源中的程序集流加载到内存中。

使用 SourceYard 源代码包，是直接将源代码合并到了目标项目里面。

使用 ILMerge / ILRepack，是在 IL 级别对程序集进行了合并。

我们可以通过下面一张图来感受一下后三种原理上的不同。

这是一个分别通过 Fody、SourceYard 和 ILMerge / ILRepack 生成的程序集的反编译图。可以看到，对于 ILRepack / ILMerge 和 SourceYard，反编译后看到的源代码都在目标程序集中，而对于 Fody，依赖仅仅出现在资源中。

适用范围

由于其原理不同，所以其适用范围和造成的副作用也不同。

如果你基于 .NET Core 3.0 开发，并且也不在意在目标计算机上生成的临时文件夹，那么可以考虑使用 PublishSingleFile 属性合并依赖。

如果你不在乎启动性能以及内存消耗，那么可以考虑 Fody（这意味着小型程序比较适合采用）。

如果你的程序非常在乎启动性能，那么就需要考虑 SourceYard、ILMerge / ILRepack 了。

对于 ILMerge / ILRepack 和 SourceYard 的比较，可以看下面这张表格：

可以发现，如果我们能够充分将我们需要的包通过 SourceYard 发布成 NuGet，那么我们将可以获得比 ILRepack / ILMerge 更好的编写和调试体验。

表格之外还有一些特别需要说明的：

1. ILRepack 额外支持修改 WPF 编译生成的 Baml 文件，将资源的引用路径修改成新程序集的路径。
2. SourceYard 的类型需要写成 private 才可以隐藏，但是只有内部类才可以写 private，因此如果特别需要隐藏，请首先写一个内部类。（因此，你可能会发现有一个类型有很多个分部类，每一个分部类中都是一个私有的内部类）

开源社区

最后说一下，以上所说的所有方法全部是开源的，有问题欢迎在社区讨论一起解决：

• .NET Foundation
• Fody/Fody
• dotnet-campus/SourceYard
• dotnet/ILMerge
• gluck/il-repack
• 0xd4d/dnSpy
• dgiagio/warp
• corert/pkg/Microsoft.DotNet.ILCompiler

如何在 .NET/C# 代码中安全地结束掉一个控制台应用程序？通过发送 Ctrl+C 信号来结束

我的电脑上每天会跑一大堆控制台程序，于是管理这些程序的运行就成了一个问题。或者说你可能也在考虑启动一个控制台程序来完成某些特定的任务。

如果我们需要结束掉这个控制台程序怎么做呢？直接杀进程吗？这样很容易出问题。我正在使用的一个控制台程序会写文件，如果直接杀进程可能导致数据没能写入到文件。所以本文介绍如何使用 .NET/C# 代码向控制台程序发送 Ctrl+C 来安全地结束掉程序。

用 Ctrl+C 结束控制台程序

如果直接用 Process.Kill 杀掉进程，进程可能来不及保存数据。所以无论是窗口程序还是控制台程序，最好都让控制台程序自己去关闭。

▲ 使用 Process.Kill 结束程序，程序退出代码是 -1

▲ 使用 Ctrl+C 结束程序，程序退出代码是 0

Ctrl+C 信号

Windows API 提供了方法可以将当前进程与目标控制台进程关联起来，这样我们便可以向自己发送 Ctrl+C 信号来结束掉关联的另一个控制台进程。

关联和取消关联的方法是下面这两个，AttachConsole 和 FreeConsole：

[DllImport("kernel32.dll")]
private static extern bool AttachConsole(uint dwProcessId);

[DllImport("kernel32.dll")]
private static extern bool FreeConsole();

不过，当发送 Ctrl+C 信号的时候，不止我们希望关闭的控制台程序退出了，我们自己程序也是会退出的（即便我们自己是一个 GUI 程序）。所以我们必须先组织自己响应 Ctrl+C 信号。

需要用到另外一个 API：

[DllImport("kernel32.dll")]
private static extern bool SetConsoleCtrlHandler(ConsoleCtrlDelegate? HandlerRoutine, bool Add);

enum CtrlTypes : uint
{
    CTRL_C_EVENT = 0,
    CTRL_BREAK_EVENT,
    CTRL_CLOSE_EVENT,
    CTRL_LOGOFF_EVENT = 5,
    CTRL_SHUTDOWN_EVENT
}

private delegate bool ConsoleCtrlDelegate(CtrlTypes CtrlType);

不过，因为我们实际上并不需要真的对 Ctrl+C 进行响应，只是单纯临时禁用以下，所以我们归这个委托传入 null 就好了。

最后，也是最关键的，就是发送 Ctrl+C 信号了：

[DllImport("kernel32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
private static extern bool GenerateConsoleCtrlEvent(CtrlTypes dwCtrlEvent, uint dwProcessGroupId);

下面，我将完整的代码贴出来。

全部源代码

using System;
using System.Diagnostics;
using System.Runtime.InteropServices;

namespace Walterlv.Fracture.Utils
{
    /// <summary>
    /// 提供与控制台程序的交互。
    /// </summary>
    public class ConsoleInterop
    {
        /// <summary>
        /// 关闭控制台程序。
        /// </summary>
        /// <param name="process">要关闭的控制台程序的进程实例。</param>
        /// <param name="timeoutInMilliseconds">如果不希望一直等待进程自己退出，则可以在此参数中设置超时。你可以在超时未推出候采取强制杀掉进程的策略。</param>
        /// <returns>如果进程成功退出，则返回 true；否则返回 false。</returns>
        public static bool StopConsoleProgram(Process process, int? timeoutInMilliseconds = null)
        {
            if (process is null)
            {
                throw new ArgumentNullException(nameof(process));
            }

            if (process.HasExited)
            {
                return true;
            }

            // 尝试将我们自己的进程附加到指定进程的控制台（如果有的话）。
            if (AttachConsole((uint)process.Id))
            {
                // 我们自己的进程需要忽略掉 Ctrl+C 信号，否则自己也会退出。
                SetConsoleCtrlHandler(null, true);

                // 将 Ctrl+C 信号发送到前面已关联（附加）的控制台进程中。
                GenerateConsoleCtrlEvent(CtrlTypes.CTRL_C_EVENT, 0);

                // 拾前面已经附加的控制台。
                FreeConsole();

                bool hasExited;
                // 由于 Ctrl+C 信号只是通知程序关闭，并不一定真的关闭。所以我们等待一定时间，如果仍未关闭，则超时不处理。
                // 业务可以通过判断返回值来角是否进行后续处理（例如强制杀掉）。
                if (timeoutInMilliseconds == null)
                {
                    // 如果没有超时处理，则一直等待，直到最终进程停止。
                    process.WaitForExit();
                    hasExited = true;
                }
                else
                {
                    // 如果有超时处理，则超时候返回。
                    hasExited = process.WaitForExit(timeoutInMilliseconds.Value);
                }

                // 重新恢复我们自己的进程对 Ctrl+C 信号的响应。
                SetConsoleCtrlHandler(null, false);

                return hasExited;
            }
            else
            {
                return false;
            }
        }

        [DllImport("kernel32.dll")]
        private static extern bool AttachConsole(uint dwProcessId);

        [DllImport("kernel32.dll")]
        private static extern bool FreeConsole();

        [DllImport("kernel32.dll")]
        private static extern bool SetConsoleCtrlHandler(ConsoleCtrlDelegate? HandlerRoutine, bool Add);

        [DllImport("kernel32.dll")]
        [return: MarshalAs(UnmanagedType.Bool)]
        private static extern bool GenerateConsoleCtrlEvent(CtrlTypes dwCtrlEvent, uint dwProcessGroupId);

        enum CtrlTypes : uint
        {
            CTRL_C_EVENT = 0,
            CTRL_BREAK_EVENT,
            CTRL_CLOSE_EVENT,
            CTRL_LOGOFF_EVENT = 5,
            CTRL_SHUTDOWN_EVENT
        }

        private delegate bool ConsoleCtrlDelegate(CtrlTypes CtrlType);
    }
}

如何使用

现在，我们可以通过调用 ConsoleInterop.StopConsoleProgram(process) 来安全地结束掉一个控制台程序。

当然，为了处理一些意外的情况，我把超时也加上了。下面的用法演示超时 2 秒候程序还没有退出，则强杀。

if (!ConsoleInterop.StopConsoleProgram(process, 2000))
{
    try
    {
        process.Kill();
    }
    catch (InvalidOperationException e)
    {
    }
}

参考资料

• signals - Can I send a ctrl-C (SIGINT) to an application on Windows? - Stack Overflow
• Stopping command-line applications programatically with Ctrl-C event from .Net – a working demo - Nemo’s Realms
• AttachConsole function - Windows Console - Microsoft Docs
• SetConsoleCtrlHandler function - Windows Console - Microsoft Docs

如何将一个 .NET 对象序列化为 HTTP GET 的请求字符串

HTTP GET 请求时携带的参数直接在 URL 中，形式如 ?key1=value&key2=value&key3=value。如果是 POST 请求时，我们可以使用一些库序列化为 json 格式作为 BODY 发送，那么 GET 请求呢？有可以直接将其序列化为 HTTP GET 请求的 query 字符串的吗？

HTTP GET 请求

一个典型的 HTTP GET 请求带参数的话大概是这样的：

https://s.blog.walterlv.com/api/example?key1=value&key2=value&key3=value

于是我们将一个类型序列化为后面的参数：

[DataContract]
public class Foo
{
    [DataMember(Name = "key1")]
    public string? Key1 { get; set; }

    [DataMember(Name = "key2")]
    public string? Key2 { get; set; }

    [DataMember(Name = "key3")]
    public string? Key3 { get; set; }
}

库？

可能是这个需求太简单了，所以并没有找到单独的库。所以我就写了一个源代码包放到了 nuget.org 上。

在这里下载源代码包：

• Walterlv.Web.Source

你不需要担心引入额外的依赖，因为这是一个源代码包。关于源代码包不引入额外依赖 dll 的原理，可以参见：

• .NET 将多个程序集合并成单一程序集的 4+3 种方法 - walterlv

方法

我们需要做的是，将一个对象序列化为 query 字符串。假设这个对象的局部变量名称是 query，于是我们需要：

1. 取得此对象所有可获取值的属性
   • query.GetType().GetProperties()
2. 获取此属性值的方法
   • property.GetValue(query, null)
3. 将属性和值拼接起来
   • string.Join("&", properties)

然而真实场景可能比这个稍微复杂一点：

1. 我们需要像 Newtonsoft.Json 一样，对于标记了 DataContract 的类，按照 DataMember 来序列化
2. URL 中的值需要进行转义

所以，我写出了下面的方法：

var isContractedType = query.GetType().IsDefined(typeof(DataContractAttribute));
var properties = from property in query.GetType().GetProperties()
                    where property.CanRead && (isContractedType ? property.IsDefined(typeof(DataMemberAttribute)) : true)
                    let memberName = isContractedType ? property.GetCustomAttribute<DataMemberAttribute>().Name : property.Name
                    let value = property.GetValue(query, null)
                    where value != null && !string.IsNullOrWhiteSpace(value.ToString())
                    select memberName + "=" + HttpUtility.UrlEncode(value.ToString());
var queryString = string.Join("&", properties);
return string.IsNullOrWhiteSpace(queryString) ? "" : prefix + queryString;

完整的代码如下：

using System.Diagnostics.CodeAnalysis;
using System.Linq;
using System.Reflection;
using System.Runtime.Serialization;
using System.Web;

namespace Walterlv.Web.Core
{
    internal class QueryString
    {
        [return: NotNullIfNotNull("query")]
        public static string? Serialize(object? query, string? prefix = "?")
        {
            if (query is null)
            {
                return null;
            }

            var isContractedType = query.GetType().IsDefined(typeof(DataContractAttribute));
            var properties = from property in query.GetType().GetProperties()
                             where property.CanRead && (isContractedType ? property.IsDefined(typeof(DataMemberAttribute)) : true)
                             let memberName = isContractedType ? property.GetCustomAttribute<DataMemberAttribute>().Name : property.Name
                             let value = property.GetValue(query, null)
                             where value != null && !string.IsNullOrWhiteSpace(value.ToString())
                             select memberName + "=" + HttpUtility.UrlEncode(value.ToString());
            var queryString = string.Join("&", properties);
            return string.IsNullOrWhiteSpace(queryString) ? "" : prefix + queryString;
        }
    }
}

你可能会遇到 [return: NotNullIfNotNull("query")] 这一行编译不通过的情况，这个是 C# 8.0 带的可空引用类型所需要的契约类。

你可以将它删除，或者安装我的另一个 NuGet 包来获得更多可空引用类型契约的支持，详见：

• C# 8.0 的可空引用类型，不止是加个问号哦！你还有很多种不同的可空玩法 - walterlv

使用正则表达式尽可能准确匹配域名/网址

你可能需要准确地知道一段字符串是否是域名/网址/URL。虽然可以使用 .、/ 这些来模糊匹配，但会造成误判。

实际上单纯使用正则表达式来精确匹配也是非常复杂的，通过代码来判断会简单很多。不过本文依然从域名的定义出发来尽可能匹配一段字符串是否是域名或者网址，在要求不怎么高的场合，使用本文的正则表达式写的代码会比较简单。

网址

网址实际上是 URL（统一资源定位符），它是由协议、主机名和路径组成。不过我们通常所说的网址中的主机名通常是域名，因此我们在匹配的时候主要考虑域名。

域名

维基百科 中关于域名的描述：

1. 域名由一或多个部分组成，这些部分通常连接在一起，并由点分隔。最右边的一个标签是顶级域名，例如zh.wikipedia.org的顶级域名是org。一个域名的层次结构，从右侧到左侧隔一个点依次下降一层。每个标签可以包含1到63个八字节。域名的结尾有时候还有一点，这是保留给根节点的，书写时通常省略，在查询时由软件内部补上。
2. 域名里的英文字母不区分大小写。
3. 完整域名的所有字符加起来不得超过253个ASCII字符的总长度。因此，当每一级都使用单个字符时，限制为127个级别：127个字符加上126个点的总长度为253。但实际上，某些域名可能具有其他限制；也没有只有一个字符的域名后缀。

后面关于非 ASCII 字符的描述我没有贴出来。这种域名例如“.中国”。

在 中国电信网站备案自助管理系统 中，我们可以找到关于域名的描述：

域名中的标号都由英文字母和数字组成，每一个标号不超过63个字符，也不区分大小写字母。标号中除连字符（-）外不能使用其他的标点符号。级别最低的域名写在最左边，而级别最高的域名写在最右边。由多个标号组成的完整域名总共不超过255个字符。

路径

路径是使用 / 分隔的一段一段字符串。

正则表达式匹配

在确认了完整的网址 URL 的规范之后，使用正则表达式来匹配就会比较精确了。

域名

现在，我们来尝试匹配一下域名 。

1. 每个标签可组成的字符是 - a-z A-Z 0-9，但是 - 不可作为开头，标签总长度 1-63 个字符，于是
   • [a-zA-Z0-9][-a-zA-Z0-9]{0,62}
   • 即首字不含 -，后面的字可以包含 -
2. 允许多个标签，于是
   • (\.[a-zA-Z0-9][-a-zA-Z0-9]{0,62})+
   • 除了标签内容和前面一样，但我们加了个 .

别忘了，我们还有总长度限制，于是考虑加上零宽断言 ^.{3,255}$，匹配开头和结尾，中间任意字符但长度在 3-255 之间。通过零宽断言，我们可以在不捕获匹配字符串的情况下对后面的字符串增加限制条件。

现在，把整个正则表达式拼出来：

^(?=^.{3,255}$)[a-zA-Z0-9][-a-zA-Z0-9]{0,62}(\.[a-zA-Z0-9][-a-zA-Z0-9]{0,62})+$

URL

对于不同的业务需求，可能有严格匹配或者宽松的匹配方式。

比如你要做一些比较精准的检查时需要进行严格的检查，那么选择严格匹配；这时，稍微出现一些不符合要求的字符都将认定为不是 URL。

如果你只是打算做一些简单的检查（例如只是语法高亮），那么简单匹配即可；因为当你使用 Chrome 浏览器访问这些 URL 的时候，依然可以正常访问，Chrome 会帮你格式化一下这个 URL。

• https://blog.walterlv.com/post/read-32bit-registry-from-x64-process.html
  • 严格匹配和宽松匹配都会成功匹配
• https://blog.lindexi.com/post/dotnet-配置-github-自动打包上传-nuget-文件.html
  • 里面有 Unicode 字符，宽松匹配才可以匹配此 URL
  • 你把这个 URL 复制到 Chrome 中可以正常打开，但从 Chrome 里把这个复制出来的话，就会被转义成 https://blog.lindexi.com/post/dotnet-%E9%85%8D%E7%BD%AE-github-%E8%87%AA%E5%8A%A8%E6%89%93%E5%8C%85%E4%B8%8A%E4%BC%A0-nuget-%E6%96%87%E4%BB%B6.html。
• https://[2001:4860:4860::8888]:53/favicon.svg
  • 因为我偷懒了，所以只有宽松匹配才可以匹配此 IPv6 地址下的 URL
• https://域名.中国
  • 因为我偷懒了，所以只有宽松匹配才可以匹配此 IPv6 地址下的 URL

URL（严格）

匹配 URL 跟匹配域名不一样，URL 复杂得多。严格匹配的要求是准确反应出 URL 的标准，但实际上如实反应标准编写的正则表达式会非常复杂，因此相比于 100% 准确匹配，我们还是从简了。

所以如果不是有特别要求，建议还是跳到后面的“宽松”部分来阅读吧！

我们以下面这个网址为例说明。

https://blog.walterlv.com/post/read-32bit-registry-from-x64-process.html

1. 前面是可选的协议名，于是
   • (http(s)?:\/\/)
   • 然而既然可选，而且是行首，那么加一个 ? 和什么都不加的效果是一样的
2. 随后是域名，于是
   • [a-zA-Z0-9][-a-zA-Z0-9]{0,62}(\.[a-zA-Z0-9][-a-zA-Z0-9]{0,62})+
   • 这里我们没有把总长度限制算上去
3. 别忘了有个可选的端口号
   • (:[0-9]{1,5})?
   • 端口号的范围是 0-65535，但 0 是保留端口，49152 到 65535 也是保留端口，因此可以作为网址访问的范围也就是 1-49151，因此我们限制 1-5 位长度。
4. 接下来是资源路径
   • 资源路径可以使用的字符也是有限制的，我们接下来详细说明。

组合整个正则表达式：

^[a-zA-Z0-9][-a-zA-Z0-9]{0,62}(\.[a-zA-Z0-9][-a-zA-Z0-9]{0,62})+(:[0-9]{1,5})?[-a-zA-Z0-9()@:%_\\\+\.~#?&//=]*$

顺便一提，不同于域名，我们这里去掉了长度限制，因为 URL 真的可以“很长”。另外，这里的

现在，我们补充说明一下资源路径可以使用的字符问题。

; / ? : @ & = + $ , 这些字符应该被转义。转义使用的字符是 &xxx;，因此在转义之后，依然还可能在网址中看到 & 和 ;，不过没有其他字符了。

- _ . ! ~ * ' ( ) 这些字符可以不进行转义，但也不建议在 URL 中使用。对于这部分，我们考虑将其匹配。

{ } | \ ^ [ ] ` 这部分字符可能被网关当作分隔符使用，因此不建议出现在 URL 中。对于这部分，我们考虑将其匹配。

< > # % " 控制字符。使用 % 可以组成其他 Unicode 字符，使用 # 用来指代网址中的某个部分。

因此，我们最终总结应该匹配的特殊字符有 @ : % _ \ + . ~ # ? & / =。

URL（宽松）

宽松一点的话，正则表达式就好写多了。

这个正则表达式可以不写 https 协议前缀：

^\w+[^\s]+(\.[^\s]+){1,}$

如果上下文中要求必须匹配 https，则可以写：

^(http(s)?:\/\/)\w+[^\s]+(\.[^\s]+){1,}$

• https://blog.walterlv.com/post/read-32bit-registry-from-x64-process.html#content)
  • 期望不匹配（主要是不能匹配末尾的括号），实际匹配
  • 在 URL 中，如果括号是成对的，则此 URL 允许以 ) 结尾，如果 URL 中括号不成对，则此 URL 不能以 ) 结尾；> 同理
• https://blog.walterlv.com/post/read-32bit -registry-from-x64-process.html
  • 期望不匹配，实际不匹配
• https://blog.lindexi.com/post/dotnet-配置-github-自动打包上传-nuget-文件.html
  • 期望匹配，实际匹配
• https://域名.中国
  • 期望匹配，实际匹配
• blog.walterlv.com/post/read-32bit-registry-from-x64-process.html
  • 期望匹配，实际匹配
• x<blog.walterlv.com/post/read-32bit-registry-from-x64-process.html
  • 期望不匹配，实际匹配

这里的宽松正则表达式请小心！此正则表达式会将一段话中 URL 后面非空格的部分都算作 URL 的一部分。

更多大牛匹配 URL 的正则表达式

在 GitHub 上还有很多大牛们在写各种匹配 URL 的正则表达式：

• regex-weburl.js

最长的一个写了 1347 个字符，最短的有 38 个字符。

有人将其整理成一张表格，一图说明各种正则表达式能匹配到什么程度：

• In search of the perfect URL validation regex

参考资料

• In search of the perfect URL validation regex
• 域名 - 维基百科，自由的百科全书
• 中国电信网站备案自助管理系统

C# 8.0 的可空引用类型，不止是加个问号哦！你还有很多种不同的可空玩法

C# 8.0 引入了可空引用类型，你可以通过 ? 为字段、属性、方法参数、返回值等添加是否可为 null 的特性。

但是如果你真的在把你原有的旧项目迁移到可空类型的时候，你就会发现情况远比你想象当中复杂，因为你写的代码可能只在部分情况下可空，部分情况下不可空；或者传入空时才可为空，传入非空时则不可为空。

C# 8.0 可空特性

在开始迁移你的项目之前，你可能需要了解如何开启项目的可空类型支持：

• C# 8.0 如何在项目中开启可空引用类型的支持 - walterlv

可空引用类型是 C# 8.0 带来的新特性。

你可能会好奇，C# 语言的可空特性为什么在编译成类库之后，依然可以被引用它的程序集识别。也许你可以理解为有什么特性 Attribute 标记了字段、属性、方法参数、返回值的可空特性，于是可空特性就被编译到程序集中了。

确实，可空特性是通过 NullableAttribute 和 NullableContextAttribute 这两个特性标记的。

但你是否好奇，即使在古老的 .NET Framework 4.5 或者 .NET Standard 2.0 中开发的时候，你也可以编译出支持可空信息的程序集出来。这些古老的框架中没有这些新出来的类型，为什么也可以携带类型的可空特性呢？

实际上反编译一下编译出来的程序集就能立刻看到结果了。

看下图，在早期版本的 .NET 框架中，可空特性实际上是被编译到程序集里面，作为 internal 的 Attribute 类型了。

所以，放心使用可空类型吧！旧版本的框架也是可以用的。

更灵活控制的可空特性

阻碍你将老项目迁移到可空类型的原因，可能还有你原来代码逻辑的问题。因为有些情况下你无法完完全全将类型迁移到可空。

例如：

1. 有些时候你不得不为非空的类型赋值为 null 或者获取可空类型时你能确保此时一定不为 null（待会儿我会解释到底是什么情况）；
2. 一个方法，可能这种情况下返回的是 null 那种情况下返回的是非 null；
3. 可能调用者传入 null 的时候才返回 null，传入非 null 的时候返回非 null。

为了解决这些情况，C# 8.0 还同时引入了下面这些 Attribute：

• AllowNull: 标记一个不可空的输入实际上是可以传入 null 的。
• DisallowNull: 标记一个可空的输入实际上不应该传入 null。
• MaybeNull: 标记一个非空的返回值实际上可能会返回 null，返回值包括输出参数。
• NotNull: 标记一个可空的返回值实际上是不可能为 null 的。
• MaybeNullWhen: 当返回指定的 true/false 时某个输出参数才可能为 null，而返回相反的值时那个输出参数则不可为 null。
• NotNullWhen: 当返回指定的 true/false 时，某个输出参数不可为 null，而返回相反的值时那个输出参数则可能为 null。
• NotNullIfNotNull: 指定的参数传入 null 时才可能返回 null，指定的参数传入非 null 时就不可能返回 null。
• DoesNotReturn: 指定一个方法是不可能返回的。
• DoesNotReturnIf: 在方法的输入参数上指定一个条件，当这个参数传入了指定的 true/false 时方法不可能返回。

想必有了这些描述后，你在具体遇到问题的时候应该能知道选用那个特性。但单单看到这些特性的时候你可能不一定知道什么情况下会用得着，于是我可以为你举一些典型的例子。

输入：AllowNull

设想一下你需要写一个属性：

public string Text
{
    get => GetValue() ?? "";
    set => SetValue(value ?? "");
}

当你获取这个属性的值的时候，你一定不会获取到 null，因为我们在 get 里面指定了非 null 的默认值。然而我是允许你设置 null 到这个属性的，因为我处理好了 null 的情况。

于是，请为这个属性加上 AllowNull。这样，获取此属性的时候会得到非 null 的值，而设置的时候却可以设置成 null。

++  [AllowNull]
    public string Text
    {
        get => GetValue() ?? "";
        set => SetValue(value ?? "");
    }

输入：DisallowNull

与以上场景相反的一个场景：

private string? _text;

public string? Text
{
    get => _text;
    set => _text = value ?? throw new ArgumentNullException(nameof(value), "不允许将这个值设置为 null");
}

当你获取这个属性的时候，这个属性可能还没有初始化，于是我们获取到 null。然而我却并不允许你将这个属性赋值为 null，因为这是个不合理的值。

于是，请为这个属性加上 DisallowNull。这样，获取此属性的时候会得到可能为 null 的值，而设置的时候却不允许为 null。

输出：MaybeNull

如果你有尝试过迁移代码到可空类型，基本上一定会遇到泛型方法的迁移问题：

public T Find<T>(int index)
{
}

比如以上这个方法，找到了就返回找到的值，找不到就返回 T 的默认值。那么问题来了，T 没有指定这是值类型还是引用类型。

如果 T 是引用类型，那么默认值 default(T) 就会引入 null。但是泛型 T 并没有写成 T?，因此它是不可为 null 的。然而值类型和引用类型的 T? 代表的是不同的含义。这种矛盾应该怎么办？

这个时候，请给返回值标记 MaybeNull：

++  [return: MaybeNull]
    public T Find<T>(int index)
    {
    }

这表示此方法应该返回一个不可为 null 的类型，但在某些情况下可能会返回 null。

实际上这样的写法并没有从本质上解决掉泛型 T 的问题，不过可以用来给旧项目迁移时用来兼容 API 使用。

如果你可以不用考虑 API 的兼容性，那么可以使用新的泛型契约 where T : notnull。

public T Find<T>(int index) where T : notnull
{
}

输出：NotNull

设想你有一个方法，方法参数是可以传入 null 的：

public void EnsureInitialized(ref string? text)
{
}

然而这个方法的语义是确保此字段初始化。于是可以传入 null 但不会返回 null 的。这个时候请标记 NotNull：

--  public void EnsureInitialized(ref string? text)
++  public void EnsureInitialized([NotNull] ref string? text)
    {
    }

NotNullWhen, MaybeNullWhen

string.IsNullOrEmpty 的实现就使用到了 NotNullWhen：

bool IsNullOrEmpty([NotNullWhen(false)] string? value);

它表示当返回 false 的时候，value 参数是不可为 null 的。

这样，你在这个方法返回的 false 判断分支里面，是不需要对变量进行判空的。

当然，更典型的还有 TryDo 模式。比如下面是 Version 类的 TryParse：

bool TryParse(string? input, [NotNullWhen(true)] out Version? result)

当返回 true 的时候，result 一定不为 null。

NotNullIfNotNull

典型的情况比如指定默认值：

[return: NotNullIfNotNull("defaultValue")]
public string? GetValue(string key, string? defaultValue)
{
}

这段代码里面，如果指定的默认值（defaultValue）是 null 那么返回值也就是 null；而如果指定的默认值是非 null，那么返回值也就不可为 null 了。

在早期 .NET Framework 或者早期版本的 .NET Core 中使用

在本文第一小节里面，我们说 Nullable 是编译到目标程序集中的，所以不需要引用什么特别的程序集就能够使用到可空引用的特性。

那么上面这些特性呢？它们并没有编译到目标程序集中怎么办？

实际上，你只需要有一个命名空间、名字和实现都相同的类型就够了。你可以写一个放到你自己的程序集中，也可以把这些类型写到一个自己公共的库中，然后引用它。当然，你也可以用我已经写好的 NuGet 包 Walterlv.NullableAttributes。

Walterlv.NullableAttributes

微软 .NET 官方的可空特性在这里：

• NullableAttributes.cs

我将其注释翻译成中文之后，也写了一份在这里：

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

如果你想简单一点，可以直接引用我的 NuGet 包：

• 作为 dll 引用：NuGet Gallery - Walterlv.NullableAttributes
• 作为源代码包引用：NuGet Gallery - Walterlv.NullableAttributes.Source

源代码包可以在不用引入其他 dll 依赖的情况下完成引用。最终你输出的程序集是不带对此包的依赖的，详见：

• .NET 将多个程序集合并成单一程序集的 4+3 种方法 - walterlv

参考资料

• Upgrade APIs for nullable reference types with attributes that define expectations for null values - Microsoft Docs

一个简单的方法：截取子类名称中不包含基类后缀的部分

基类是 MenuItem，子类是 WalterlvMenuItem、FooMenuItem。基类是 Configuration，子类是 WalterlvConfiguration、ExtensionConfiguration。在代码中，我们可能会为了能够一眼看清类之间的继承（从属）关系而在子类名称后缀中带上基类的名称。但是由于这种情况下的基类不参与实际的业务，所以对外（文件/网络）的名称通常不需要带上这个后缀。

本文提供一个简单的方法，让子类中基类的后缀删掉，只取得前面的那部分。

在这段代码中，我们至少需要获得两个传入的参数，一个是基类的名称，一个是子类的名称。但是考虑到让开发者就这样传入两者名称的话会比较容易出问题，因为开发者可能根本就不会按照要求去获取类型的名称。所以我们需要自己通过类型对象来获取名称。

另外，我们还需要有一些约束，必须有一个类型是另外一个类型的子类。于是我们可能必须来使用泛型做这样的约束。

于是，我们可以写出下面的方法：

using System;

namespace Walterlv.Utils
{
    /// <summary>
    /// 包含类名相关的处理方法。
    /// </summary>
    internal static class ClassNameUtils
    {
        /// <summary>
        /// 当某个类型的派生类都以基类（<typeparamref name="T"/>）名称作为后缀时，去掉后缀取派生类名称的前面部分。
        /// </summary>
        /// <typeparam name="T">名称统一的基类名称。</typeparam>
        /// <param name="this">派生类的实例。</param>
        /// <returns>去掉后缀的派生类名称。</returns>
        internal static string GetClassNameWithoutSuffix<T>(this T @this)
        {
            if (@this is null)
            {
                throw new ArgumentNullException(nameof(@this));
            }

            var derivedTypeName = @this.GetType().Name;
            var baseTypeName = typeof(T).Name;
            // 截取子类名称中去掉基类后缀的部分。
            var name = derivedTypeName.EndsWith(baseTypeName, StringComparison.Ordinal)
                ? derivedTypeName.Substring(0, derivedTypeName.Length - baseTypeName.Length)
                : derivedTypeName;
            // 如果子类名称和基类完全一样，则直接返回子类名称。
            return string.IsNullOrWhiteSpace(name) ? derivedTypeName : name;
        }
    }
}

我们通过判断子类是否以基类名称作为后缀来决定是否截取子字符串。

在截取完子串之后，我们还需要验证截取的字符串是否已经是空串了，因为父子类的名称可能是完全一样的（虽然这样的做法真的很逗比）。

于是使用起来只需要简单调用一下：

class Program
{
    static void Main(string[] args)
    {
        var name = ClassNameUtils.GetClassNameWithoutSuffix<Foo>(new XFoo());
    }
}

internal class Foo
{

}

internal class XFoo : Foo
{

}

于是我们可以得到 name 局部变量的值为 X。如果这个时候我们对 XFoo 类型改名，例如改成 XFoo1，那么就不会截取，而是直接得到名称 XFoo1。

C# 可空引用类型 Nullable 更强制的约束：将警告改为错误 WarningsAsErrors

程序员不看警告！

于是 C# 8.0 带来的可空引用类型由于默认以警告的形式出现，所以实际上约束力非常弱。

本文将把 C# 8.0 的可空引用类型警告提升为错误，以提高约束力。

启用可空引用类型

你需要先在你的项目中启用可空引用类型的支持，才能修改警告到错误：

• C# 8.0 如何在项目中开启可空引用类型的支持 - 吕毅

项目属性

在项目属性中设置是比较快捷直观的方法。

在项目上右键属性，打开“生成”标签。

在这里，可以看到“将警告视为错误”一栏：

• 无
• 所有
• 特定警告

可以看到默认选中的是“特定警告”且值是 NU1605。

NU 是 NuGet 中发生的错误或者警告的前缀，NU1605 是大家可能平时经常见到的一个编译错误“检测到包降级”。关于这个错误的信息可以阅读官网：NuGet Warning NU1605 - Microsoft Docs，本文不需要说明。

于是，我们将我们需要视为错误的错误代码补充到后面就可以，以分号分隔。

NU1605;CS8600;CS8602;CS8603;CS8604;CS8618;CS8625

这些值的含义可以参考我的另一篇博客：

• C# 8.0 可空引用类型中的各项警告和错误 - 吕毅

记得在改之前，把前面的配置从“活动”改为“所有配置”，这样你就不用改完之后仅在 Debug 生效，完了还要去 Release 配置再改一遍。

WarningsAsErrors

前面使用属性面板指定时，有一个奇怪的默认值。实际上我们直接修改将固化这个默认值，这不利于将来项目跟随 Sdk 或者 NuGet 包的升级。

所以，最好我们能直接修改到项目文件，以便更精细地控制这个属性的值。

在上一节界面中设置实际上是生成了一个属性 WarningsAsErrors。那么我们现在修改 WarningsAsErrors 属性的值，使其拼接之前的值：

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

      <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>netcoreapp3.0</TargetFramework>
        <LangVersion>latest</LangVersion>
        <Nullable>enable</Nullable>
++      <WarningsAsErrors>$(WarningsAsErrors);CS8600;CS8601;CS8602;CS8603;CS8604;CS8609;CS8610;CS8616;CS8618;CS8619;CS8622;CS8625</WarningsAsErrors>
      </PropertyGroup>

    </Project>

这句话的含义是先获取之前的值，将其放到我们要设置的值的前面。这样可以跟随 Sdk 或者 NuGet 包的升级而更新此默认值。

这些值的含义可以参考我的另一篇博客：

• C# 8.0 可空引用类型中的各项警告和错误 - 吕毅

参考资料

• Switch to errors instead of warnings for nullable reference types in C# 8 - tabs ↹ over ␣ ␣ ␣ spaces by Jiří {x2} Činčura
• NuGet Warning NU1605 - Microsoft Docs

C# 8.0 如何在项目中开启可空引用类型的支持

C# 8.0 引入了可为空引用类型和不可为空引用类型。由于这是语法级别的支持，所以比传统的契约式编程具有更强的约束力。更容易帮助我们消灭 null 异常。

本文将介绍如何在项目中开启 C# 8.0 的可空引用类型的支持。

使用 Sdk 风格的项目文件

如果你还在使用旧的项目文件，请先升级成 Sdk 风格的项目文件：将 WPF、UWP 以及其他各种类型的旧 csproj 迁移成 Sdk 风格的 csproj - 吕毅。

本文会示例一个项目文件。

由于现在 C# 8.0 还没有正式发布，所以如果要启用 C# 8.0 的语法支持，需要在项目文件中设置 LangVersion 属性为 8.0 而不能指定为 latest 等正式版本才能使用的值。

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

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <LangVersion>8.0</LangVersion>
  </PropertyGroup>

</Project>

在项目文件中开启可空引用类型的支持

在项目属性中添加一个属性 NullableContextOptions：

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

      <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>netcoreapp3.0</TargetFramework>
        <LangVersion>latest</LangVersion>
++      <Nullable>enable</Nullable>
      </PropertyGroup>

    </Project>

此属性可被指定为以下四个值之一：

• enable
  • 所有引用类型均被视为不可为空，启用所有 null 相关的警告。
• warnings
  • 不会判定类型是否可空或不可为空，但启用局部范围内的 null 相关的警告。
• annotations
  • 所有引用类型均被视为不可为空，但关闭 null 相关的警告。
• disable
  • 与 8.0 之前的 C# 行为相同，即既不认为类型不可为空，也不启用 null 相关的警告。

这五个值其实是两个不同维度的设置排列组合之后的结果：

• 可为空注释上下文
  • 用于告知编译器是否要识别一个类型的引用可为空或者不可为空。
• 可为空警告上下文
  • 用于告知编译器是否要启用 null 相关的警告，以及警告的级别。

当仅仅启用警告上下文而不开启可为空注释上下文，那么编译器将仅仅识别局部变量中明显可以判定出对 null 解引用的代码，而不会对包括变量或者参数定义部分进行分析。

将警告视为错误

以上只是警告，如果你希望更严格地执行可空引用的建议，可以考虑使用编译错误：

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

      <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>netcoreapp3.0</TargetFramework>
++      <LangVersion>latest</LangVersion>
++      <Nullable>enable</Nullable>
++      <WarningsAsErrors>$(WarningsAsErrors);CS8600;CS8601;CS8602;CS8603;CS8604;CS8609;CS8610;CS8616;CS8618;CS8619;CS8622;CS8625</WarningsAsErrors>
      </PropertyGroup>

    </Project>

详见：

• C# 可空引用类型 NullableReferenceTypes 更强制的约束：将警告改为错误 WarningsAsErrors - walterlv
• C# 8.0 可空引用类型中的各项警告/错误的含义和示例代码 - walterlv

可为空注释（Annotation）上下文

当启动可为空注释上下文后，C# 编译器会将所有的类型引用变量识别为以下种类：

• 不可为空
• 可为空
• 未知

于是，当你写出 string walterlv 的变量定义，那么 walterlv 就是不可为空的引用类型；当写出 string? walterlv 的变量定义，那么 walterlv 就是可为空的引用类型。

对于类型参数来说，可能不能确定是否是可空引用类型，那么将视为“未知”。

当关闭可为空注释上下文后，C# 编译器会将所有类型引用变量识别为以下种类：

• 无视

于是，无论你使用什么方式顶一个一个引用类型的变量，C# 编译器都不会判定这到底是不是一个可为空还是不可为空的引用类型。

可为空警告上下文

例如以下代码：

string walterlv = null;
var value = walterlv.ToString();

在将 null 赋值给 walterlv 变量时，是不会引发程序异常的；而在后面调用了 ToString() 方法则会引发程序异常。

安全性区别就在这里。安全性警告仅会将编译期间可识别到可能运行时异常的代码进行警告（即下面的 walterlv.ToString()），而不会对没有异常的代码进行警告。如果是 enable，那么将 null 赋值给 walterlv 变量的那一句也会警告。

在源代码文件中开启可空引用类型的支持

除了在项目文件中全局开启可空引用类型的支持，也可以在 C# 源代码文件中覆盖全局的设定。

• #nullable enable: 在源代码中启用可空引用类型并给出警告。
• #nullable disable: 在源代码中禁用可空引用类型并关闭警告。
• #nullable restore: 还原这段代码中可空引用类型和可空警告。
• #nullable disable warnings: 在源代码中禁用可空警告。
• #nullable enable warnings: 在源代码中启用可空警告。
• #nullable restore warnings: 还原这段代码中可空警告。
• #nullable disable annotations: 在源代码中禁用可空引用类型。
• #nullable enable annotations: 在源代码中启用用可空引用类型。
• #nullable restore annotations: 还原这段代码中可空引用类型。

早期版本的属性

在接近正式版的时候，开关才是 Nullable，而之前是 NullableContextOptions，但在 Visual Studio 2019 Preview 2 之前，则是 NullableReferenceTypes。现在，这些旧的属性已经废弃。

ReSharper 支持

ReSharper 从 2019.1.1 版本开始支持 C# 8.0，如果使用早期版本，就会到处报错。

但是，由于 C# 8.0 可空引用类型的特性总在变，所以建议使用 2019.2.3 或以上版本，这是 C# 8.0 正式版本发布之后的 ReSharper。

参考资料

• Nullable reference types - Microsoft Docs
• c# - What is the difference between NullableContextOptions and NullableReferenceTypes? - Stack Overflow

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

C# 8.0 可空引用类型中的各项警告/错误的含义和示例代码

C# 8.0 引入了可为空引用类型和不可为空引用类型。当你需要给你或者团队更严格的要求时，可能需要定义这部分的警告和错误级别。

本文将介绍 C# 可空引用类型部分的警告和错误提示，便于进行个人项目或者团队项目的配置。

开启可空引用类型以及配置警告和错误

本文的内容本身没什么意义，但如果你试图进行一些团队配置，那么本文的示例可能能带来一些帮助。

• C# 8.0 如何在项目中开启可空引用类型的支持 - 吕毅
• C# 可空引用类型 NullableReferenceTypes 更强制的约束：将警告改为错误 WarningsAsErrors - 吕毅

警告和错误

CS8600

将 null 文本或可能的 null 值转换为非 null 类型。

string walterlv = null;

CS8601

可能的 null 引用赋值。

string Text { get; set; }

void Foo(string? text)
{
    // 将可能为 null 的文本向不可为 null 的类型赋值。
    Text = text;
}

CS8602

null 引用可能的取消引用。

// 当编译器判定 walterlv 可能为 null 时才会有此警告。
var value = walterlv.ToString();

CS8603

可能的 null 引用返回。

string Foo()
{
    return null;
}

CS8604

将可能为 null 的引用作为参数传递到不可为 null 的方法中：

void Foo()
{
    string text = GetText();;
    Bar(text);
}

string? GetText()
{
    return null;
}

CS8609

返回类型中引用类型的为 Null 性与重写成员不匹配。

比如你的基类中返回值不允许为 null，但是实现中返回值却允许为 null。

protected virtual async Task<string> FooAsync()
{
}

protected override async Task<string?> FooAsync()
{
}

CS8610

参数中引用类型的为 Null 性与重写成员不匹配。

比如你的基类中方法参数值不允许为 null，但是实现中方法参数却允许为 null。

protected virtual void FooAsync(string value)
{
}

protected override void FooAsync(string? value)
{
}

CS8616

接口中定义的成员中的 null 性与实现中成员的 null 型不匹配。

比如你的接口中不允许为 null，但是实现中却允许为 null。

CS8618

未初始化不可以为 null 的字段 “_walterlv”。

如果一个类型中存在不可以为 null 的字段，那么需要在构造函数中初始化，如果没有初始化，则会发出警告或者异常。

CS8619

一个类型与构造这个类型的 null 性不匹配。

例如：

Task<object?> foo = new Task<object>(() => new object());

CS8622

委托定义的参数中引用类型的为 null 性与目标委托不匹配。

比如你定义了一个委托：

void Foo(object? sender, EventArgs e);

然而在订阅事件的时候，使用的函数 null 性不匹配，则会出现警告：

void OnFoo(object sender, EventArgs e)
{
    // 注意到这里的 object 本应该写作 object?
}

CS8625

无法将 null 文本转换为非 null 引用或无约束类型参数。

void Foo(string walterlv = null)
{
}

CS8653

对于泛型 T，使用 default 设置其值。如果 T 是引用类型，那么 default 就会将这个泛型类型赋值为 null。然而并没有将泛型 T 的使用写为 T?。

C#/.NET 当我们在写事件 += 和 -= 的时候，方法是如何转换成事件处理器的

当我们在写 += 和 -= 事件的时候，我们会在 += 或 -= 的右边写上事件处理函数。我们可以写很多种不同的事件处理函数的形式，那么这些形式都是一样的吗？如果你不注意，可能出现内存泄漏问题。

本文将讲解事件处理函数的不同形式，理解了这些可以避免编写代码的时候出现内存相关的问题。

典型的事件处理函数

事件处理函数本质上是一个委托，比如 FileSystemWatcher 的 Changed 事件是这样定义的：

// 这是简化的代码。
public event FileSystemEventHandler Changed;

这里的 FileSystemEventHandler 是一个委托类型：

public delegate void FileSystemEventHandler(object sender, FileSystemEventArgs e);

一个典型的事件的 += 会像下面这样：

void Subscribe(FileSystemWatcher watcher)
{
    watcher.Changed += new FileSystemEventHandler(OnChanged);
}

void OnChanged(object sender, FileSystemEventArgs e)
{
}

+= 的右边传入的是一个 new 出来的委托实例。

变种事件处理函数

除了上面直接创建的目标类型的委托之外，还有其他类型可以放到 += 的右边：

// 方法组。
watcher.Changed += OnChanged;

// Lambda 表达式。
watcher.Changed += (sender, e) => Console.WriteLine(e.ChangeType);

// Lambda 表达式。
watcher.Changed += (sender, e) =>
{
    // 事件引发时，代码会在这里执行。
};

// 匿名方法。
watcher.Changed += delegate (object sender, FileSystemEventArgs e)
{
    // 事件引发时，代码会在这里执行。
};

// 委托类型的局部变量（或者字段）。
FileSystemEventHandler onChanged = (sender, e) => Console.WriteLine(e.ChangeType);
watcher.Changed += onChanged;

// 局部方法（或者局部静态方法）。
watcher.Changed += OnChanged;
void OnChanged(object sender, FileSystemEventArgs e)
{
}

因为我们可以通过编写事件的 add 和 remove 方法来观察事件 += -= 传入的 value 是什么类型的什么实例，所以可以很容易验证以上每一种实例最终被加入到事件中的真实实例。

实际上我们发现，无论哪一个，最终传入的都是 FileSystemEventHandler 类型的实例。

然而我们知道，只有直接 new 出来的那个和局部变量那个真正是 FileSystemEventHandler 类型的实例，其他都不是。

那么中间发生了什么样的转换使得我们所有种类的写法最终都可以 += 呢？

编译器类型转换

具有相同签名的不同委托类型，彼此之前并没有继承关系，因此在运行时是不可以进行类型转换的。

比如：

FileSystemEventHandler onChanged1 = (sender, e) => Console.WriteLine(e.ChangeType);
Action<object, FileSystemEventArgs> onChanged2 = (sender, e) => Console.WriteLine(e.ChangeType);

这里，onChanged1 的实例不可以赋值给 onChanged2，反过来 onChanged2 的实例也不可以赋值给 onChanged1。于是这里只有 onChanged1 才可以作为 Changed 事件 += 的右边，而 onChanged2 放到 += 右边是会出现编译错误的。

然而，我们可以放 Lambda 表达式，可以放匿名函数，可以放方法组，也可以放局部函数。因为这些类型可以在编译期间，由编译器帮助进行类型转换。而转换的效果就类似于我们自己编写 new FileSystemEventHandler(xxx) 一样。

不是同一个委托实例

看下面这一段代码，你认为可以 -= 成功吗？

void Subscribe(FileSystemWatcher watcher)
{
    watcher.Changed += new FileSystemEventHandler(OnChanged);
    watcher.Changed -= new FileSystemEventHandler(OnChanged);
}

void OnChanged(object sender, FileSystemEventArgs e)
{
}

实际上这是可以 -= 成功的。

我们平时编写代码的时候，下面的情况可能会多一些，于是自然而然以为 += 和 -= 可以成功，因为他们“看起来”是同一个实例：

watcher.Changed += OnChanged;
watcher.Changed -= OnChanged;

在读完刚刚那一段之后，我们就可以知道，实际上这一段和上面 new 出来委托的写法在运行时是一模一样的。

如果你想测试，那么在 += 的时候为对象加上一个 Id，在 -= 的时候你就会发现这是一个新对象（因为没有 Id）。

然而，你平时众多的编码经验会告诉你，这里的 -= 是一定可以成功的。也就是说，+= 和 -= 时传入的委托实例即便不是同一个，也是可以成功 += 和 -= 的。

+= -= 是怎么做的

+= 和 -= 到底是怎么做的，可以在不同实例时也能 += 和 -= 成功呢？

+= 和 -= 实际上是调用了 Delegate 的 Combine 和 Remove 方法，并生成一个新的委托实例赋值给 += -= 的左边。

public event FileSystemEventHandler Changed
{
    add
    {
        onChangedHandler = (FileSystemEventHandler)Delegate.Combine(onChangedHandler, value);
    }
    remove
    {
        onChangedHandler = (FileSystemEventHandler)Delegate.Remove(onChangedHandler, value);
    }
}

而最终的判断也是通过 Delegate 的 Equals 方法来比较委托的实例是否相等的（== 和 != 也是调用的 Equals）：

public override bool Equals(object? obj)
{
    if (obj == null || !InternalEqualTypes(this, obj))
        return false;

    Delegate d = (Delegate)obj;

    // do an optimistic check first. This is hopefully cheap enough to be worth
    if (_target == d._target && _methodPtr == d._methodPtr && _methodPtrAux == d._methodPtrAux)
        return true;

    // even though the fields were not all equals the delegates may still match
    // When target carries the delegate itself the 2 targets (delegates) may be different instances
    // but the delegates are logically the same
    // It may also happen that the method pointer was not jitted when creating one delegate and jitted in the other
    // if that's the case the delegates may still be equals but we need to make a more complicated check

    if (_methodPtrAux == IntPtr.Zero)
    {
        if (d._methodPtrAux != IntPtr.Zero)
            return false; // different delegate kind
        // they are both closed over the first arg
        if (_target != d._target)
            return false;
        // fall through method handle check
    }
    else
    {
        if (d._methodPtrAux == IntPtr.Zero)
            return false; // different delegate kind

        // Ignore the target as it will be the delegate instance, though it may be a different one
        /*
        if (_methodPtr != d._methodPtr)
            return false;
            */

        if (_methodPtrAux == d._methodPtrAux)
            return true;
        // fall through method handle check
    }

    // method ptrs don't match, go down long path
    //
    if (_methodBase == null || d._methodBase == null || !(_methodBase is MethodInfo) || !(d._methodBase is MethodInfo))
        return Delegate.InternalEqualMethodHandles(this, d);
    else
        return _methodBase.Equals(d._methodBase);
}

于是可以看出来，判断相等就是两个关键对象的判断相等：

1. 方法所在的对象
2. 方法信息（对应到反射里的 MethodInfo)

继续回到这段代码：

void Subscribe(FileSystemWatcher watcher)
{
    watcher.Changed += new FileSystemEventHandler(OnChanged);
    watcher.Changed -= new FileSystemEventHandler(OnChanged);
}

void OnChanged(object sender, FileSystemEventArgs e)
{
}

这里的对象就是 this，方法信息就是 OnChanged 的信息，也就是：

// this 就是对象，OnChanged 就是方法信息。
this.OnChanged

-=

于是什么样的 -= 才可以把 += 加进去的事件处理函数减掉呢？

• 必须是同一个对象的同一个方法

所以：

1. 使用方法组、静态局部函数、委托字段的方式创建的委托实例，在 += 和 -= 的时候无视哪个委托实例，都是可以减掉的；
2. 使用局部函数、委托变量，在同一个上下文中，是可以减掉的，如果调用是再次进入此函数，则不能减掉（因为委托方法所在的对象实例不同）
3. 使用 Lambda 表达式、匿名函数是不能减掉的，因为每次编写的 Lambda 表达式和匿名函数都会创建新的包含此对象的实例。

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

有小伙伴希望在 .NET 代码中使用指针，操作非托管资源，于是可能使用到 unsafe fixed 关键字。但使用此关键字的前提是需要在项目中开启不安全代码。

本文介绍如何在项目中开启不安全代码。

入门方法

第一步：在你需要启用不安全代码的项目上点击右键，然后选择属性：

第二步：在“生成”标签下，勾选上“允许不安全代码”：

第三步：切换到 Release 配置，再勾上一次“允许不安全代码”（确保 Debug 和 Release 都打开）

方法结束。

如果你一开始选择了“所有配置”，那么就不需要分别在 Debug 和 Release 下打开了，一次打开即可。

高级方法

推荐

如果你使用 .NET Core / .NET Standard 项目，那么你可以修改项目文件来实现，这样项目文件会更加清真。

第一步：在你需要启用不安全代码的项目上点击右键，然后选择编辑项目文件：

第二步：在你的项目文件的属性组中添加一行 <AllowUnsafeBlocks>true</AllowUnsafeBlocks>：

我已经把需要新增的行高亮出来了

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

      <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>netcoreapp3.0</TargetFramework>
++      <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
      </PropertyGroup>

    </Project>

临时方法

不推荐

如果你只是临时希望加上不安全代码开关，则可以在编译的时候加入 -unsafe 命令行参数：

csc -unsafe walterlv.cs

注意，不能给 msbuild 或者 dotnet build 加上 -unsafe 参数来编译项目，只能使用 csc 加上 -unsafe 来编译文件。因此使用场景非常受限，不推荐使用。

其他说明

第一种方法（入门方法）和第二种方法（高级方法）最终的修改是有一些区别的。入门方法会使得项目文件中有针对于 Debug 和 Release 的不同配置，代码会显得冗余；而高级方法中只增加了一行，对任何配置均生效。

因此如果可能，尽量使用高级方法呗。

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

      <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>netcoreapp3.0</TargetFramework>
++      <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
      </PropertyGroup>

--    <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
--      <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
--    </PropertyGroup>

--    <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
--      <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
--    </PropertyGroup>

    </Project>

即使是 .NET Framework 也是可以使用 SDK 风格的项目文件的，详情请阅读：

• 将 WPF、UWP 以及其他各种类型的旧 csproj 迁移成 Sdk 风格的 csproj - walterlv

不要在 C# 代码中写部分命名空间（要么不写，要么写全），否则会有源码兼容性问题

我只是增加库的一个 API，比如增加几个类而已，应该不会造成兼容性问题吧。对于编译好的二进制文件来说，不会造成兼容性问题；但——可能造成源码不兼容。

本文介绍可能的源码不兼容问题。

This post is written in multiple languages. Please select yours:

比如我有一个项目 P 引用 A 和 B 两个库。其中使用到了 A 库中的 Walterlv.A.Diagnostics.Foo 类型。

using Walterlv.A;
using Walterlv.B;

namespace Walterlv.Demo
{
    class Hello
    {
        Run(Diagnostics.Foo foo)
        {
        }
    }
}

现在，我们在 B 库中新增一个类型 Walterlv.B.Diagnostics.Bar 类型。

那么上面的代码将无法完成编译，因为 Diagnosis 命名空间将具有不确定的含义，其中的 Foo 类型也将无法在不确定的命名空间中找到。

因此：

1. 强烈建议遵守 使用类型的时候，要么不写命名空间（完全留给 using），要么写全命名空间（从第一段开始写，不要省略任何部分），否则就容易与其他命名空间冲突；
2. 可选遵守 在库中新增 API 的时候，可能需要考虑避免将部分命名空间写成过于通用的名称。

是的，即使是单纯的新增 API 也可能会导致使用库的一方在源码级不兼容。当然二进制还是兼容的。

另外，OpportunityLiu 提醒，如果命名空间是 Walterlv.B.Walterlv.A.Diagnostics.Bar，一样可以让写全了的命名空间炸掉。呃……还是不要在库里面折腾这样的命名空间好……不然代码当中到处充斥着 global:: 可是非常难受的。

.NET/C# 在 64 位进程中读取 32 位进程重定向后的注册表

我们知道，32 位程序在读取注册表的时候，会自动将注册表的路径映射到 32 位路径下，即在 Wow6432Node 子节点下。但是 64 位程序不会映射到 32 位路径下。那么 64 位程序如何读取到 32 位程序写入的注册表路径呢？

Wow6432Node

对于 32 位程序，读取注册表路径的时候，会读到 Wow6432Node 节点下的项：

这张图读取的就是前面截图中的节点。

那么怎样编译的程序是 32-bit 的程序呢？

对于 64 位程序，读取的时候就不会有 Wow6432Node 路径部分。由于我没有在那个路径放注册表项，所以会得到 null。

那么怎样编译的程序是 64-bit 的程序呢？

如何在 64 位程序中读取 32 位注册表路径

前面我们的例子代码是这样的：

var value = RegistryHive.LocalMachine.Read(@"SOFTWARE\Walterlv");

可以看到，相同的代码，在 32 位和 64 位进程下得到的结果是不同的：

• 32 位进程在 32 位系统上，64 位进程在 64 位系统上，读取的路径会是传入的路径；
• 32 位进程在 64 位系统上，读取的路径会包含 Wow6432Node。

那么如何在 64 位进程中读取 32 位注册表路径呢？

方法是在打开注册表项的时候，传入 RegistryView.Registry32。

RegistryKey.OpenBaseKey(root, RegistryView.Registry32);

Walterlv.Win32

可以在我的 GitHub 仓库中查看完整的实现。当然，除了上面那句话，其他都不是关键代码，在哪里都可以找得到的。

参考资料

• c# - Reading the registry and Wow6432Node key - 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，此方法要求窗口句柄依然有效，然而此时窗口已经关闭，句柄已经销毁。

解决

将 Direct3D11 在 GPU 中的纹理（Texture2D）导出到内存（Map）或导出成图片文件

Direct3D11 的使用通常不是应用程序唯一的部分，于是使用 Direct3D11 的代码如何与其他模块正确地组合在一起就是一个需要解决的问题。

本文介绍将 Direct3D11 在 GPU 中绘制的纹理映射到内存中，这样我们可以直接观察到此纹理是否是正确的，而不用担心是否有其他模块影响了最终的渲染过程。

SharpDX

本文的代码会使用到 SharpDX 库，因此，你需要在你的项目当中安装这些 NuGet 包：

<!-- 基础，必装 -->
<PackageReference Include="SharpDX" Version="4.2.0" />
<PackageReference Include="SharpDX.D3DCompiler" Version="4.2.0" />
<PackageReference Include="SharpDX.DXGI" Version="4.2.0" />
<PackageReference Include="SharpDX.Mathematics" Version="4.2.0" />
<PackageReference Include="SharpDX.Direct3D11" Version="4.2.0" />

<!-- 其他，可选 -->
<PackageReference Include="SharpDX.Direct2D1" Version="4.2.0" />
<PackageReference Include="SharpDX.Direct3D9" Version="4.2.0" />

来自于 Direct3D11 的渲染纹理

本文不会说如何创建或者获取来自 Direct3D11 的渲染纹理，不过如果你希望了解，可以：

• 自己创建：WPF 使用封装的 SharpDx 控件
• 或者从其他进程/模块获取：使用 Direct3D11 的 OpenSharedResource 方法渲染来自其他进程/设备的共享资源（SharedHandle）

本文接下来的内容，是在你已经获得了 SharpDX.Direct3D11.Resource 的引用，或者 SharpDX.Direct3D11.Texture2D 的前提之下。当然，如果你获得了其中任何一个实例，可以通过 COM 组件的 QueryInterface 方法获得其他实例。

var texture = resource.QueryInterface<SharpDX.Direct3D11.Texture2D>();

var resource = texture.QueryInterface<SharpDX.Direct3D11.Resource>();

关键代码（SharpDX.DXGI.Surface.Map）

要获得 GPU 中渲染的图片，我们必须要将其映射到内存中才行。而映射到内存中的核心代码是 SharpDX.DXGI.Surface 对象的 Map 方法。

using (var surface = texture2D.QueryInterface<SharpDX.DXGI.Surface>())
{
    var map = surface.Map(SharpDX.DXGI.MapFlags.Read, out DataStream dataStream);
    for (var y = 0; y < surface.Description.Height; y++)
    {
        for (var x = 0; x < surface.Description.Width; x++)
        {
            // 在这里使用位图的像素数据，坐标为 (x, y)。
            // 得到此坐标下的像素指针：
            //     var ptr = ((byte*)map.DataPointer) + y * map.Pitch;
            // 得到此像素的颜色值：
            //     var b = *(ptr + 4 * x);
            //     var g = *(ptr + 4 * x + 1);
            //     var r = *(ptr + 4 * x + 2);
            //     var a = *(ptr + 4 * x + 3);
        }
    }
    dataStream.Dispose();
    surface.Unmap();
}

注意以上代码使用了不安全代码（指针），你需要为你的项目开启不安全代码开关，详见：

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

你可能需要拷贝资源

实际上，在使用上面的代码时，你可能会遇到错误，错误出现在 Map 方法的调用上，描述为“参数错误”。实际上真正检查这里的两个参数时并不能发现究竟是哪个参数出了问题。

实际上出问题的参数是 surface 的实例。

一段 GPU 中的纹理要能够被映射到内存，必须要具有 CPU 的访问权。而是否具有 CPU 访问权在创建纹理的时候就已经确定下来了。

如果前面你得到的纹理是自己创建的，那么恭喜你，你只需要改一下创建纹理的参数就好了。给 Texture2DDescription 的 CpuAccessFlags 属性加上 CpuAccessFlags.Read 标识。

desc.CpuAccessFlags = CpuAccessFlags.Read；

但是，如果此纹理不是由你自己创建的，那么就需要拷贝一份新的纹理了。当然，拷贝过程发生在 GPU 中，占用的也是 GPU 专用内存（即显存，如果有的话）。

拷贝需要做到两点：

1. 创建一个新的 Texture2DDescription（一定要是新的实例，你不能影响原来的实例），然后修改其 CPU 访问权限为 Read；
2. 使用 ImmediateContext 实例的 CopyResource 方法来拷贝资源（此实例可以通过 SharpDX.Direct3D11.Device 来找到）。

var originalDesc = originalTexture.Description;
var desc = new Texture2DDescription
{
    CpuAccessFlags = CpuAccessFlags.Read,
    BindFlags = BindFlags.None,
    Usage = ResourceUsage.Staging,
    Width = originalDesc.Width,
    Height = originalDesc.Height,
    Format = originalDesc.Format,
    MipLevels = 1,
    ArraySize = 1,
    SampleDescription =
    {
        Count = 1,
        Quality = 0
    },
};

var texture2D = new Texture2D(device, desc);
device.ImmediateContext.CopyResource(originalTexture, texture2D);

需要注意，拷贝纹理会额外占用显存，一般不建议这么做，除非你真的有需求一定要 CPU 能够访问到这段纹理。

导出成图片文件

实际上，当你组合起来以上以上方法，你应该能够将纹理导出成图片了。

不过，为了理解更方便一些，我还是将导出成图片的全部代码贴出来：

public static unsafe void MapTexture2DToFile(SharpDX.Direct3D11.Texture2D texture, string fileName)
{
    // 获取 Texture2D 的相关实例。
    var device = texture.Device;
    var originDesc = texture.Description;

    // 创建新的 Texture2D 对象。
    var desc = new Texture2DDescription
    {
        CpuAccessFlags = CpuAccessFlags.Read,
        BindFlags = BindFlags.None,
        Usage = ResourceUsage.Staging,
        Width = originDesc.Width,
        Height = originDesc.Height,
        Format = originDesc.Format,
        MipLevels = 1,
        ArraySize = 1,
        SampleDescription =
        {
            Count = 1,
            Quality = 0
        },
        OptionFlags = ResourceOptionFlags.Shared
    };
    var texture2D = new Texture2D(device, desc);

    // 拷贝资源。
    device.ImmediateContext.CopyResource(texture, texture2D);

    var bitmap = new System.Drawing.Bitmap(desc.Width, desc.Height);
    using (var surface = texture2D.QueryInterface<SharpDX.DXGI.Surface>())
    {
        var map = surface.Map(SharpDX.DXGI.MapFlags.Read, out DataStream dataStream);
        var lines = (int)(dataStream.Length / map.Pitch);
        var actualWidth = surface.Description.Width * 4;
        for (var y = 0; y < desc.Height; y++)
        {
            var h = desc.Height - y;
            var ptr = ((byte*)map.DataPointer) + y * map.Pitch;

            for (var x = 0; x < desc.Width; x++)
            {
                var b = *(ptr + 4 * x);
                var g = *(ptr + 4 * x + 1);
                var r = *(ptr + 4 * x + 2);
                var a = *(ptr + 4 * x + 3);
                bitmap.SetPixel(x, y, System.Drawing.Color.FromArgb(a, r, g, b));
            }
        }
        dataStream.Dispose();
        surface.Unmap();
        bitmap.Save(fileName);
    }
}

如果你是希望以纯软件的方式渲染到 WPF 中（WriteableBitmap），可以参考：

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

记得打开不安全代码开关哦！详见：

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

参考资料

• c++ - How to access pixels data from ID3D11Texture2D? - Stack Overflow
• SharpDX Directx11 How to add normal mapping ? - Graphics and GPU Programming - GameDev.net
• directx 11 - How to create bitmap from Surface (SharpDX) - Stack Overflow
• Desktop Duplication API - Windows applications - Microsoft Docs
• c# - Reading Datastream sharpDX Error all values are 0 - Stack Overflow
• SharpDX-Samples/Program.cs at master · sharpdx/SharpDX-Samples

.NET 实现 NTFS 文件系统的硬链接 mklink /J（Junction）

我们知道 Windows 系统 NTFS 文件系统提供了硬连接功能，可以通过 mklink 命令开启。如果能够通过代码实现，那么我们能够做更多有趣的事情。

本文提供使用 .NET/C# 代码创建 NTFS 文件系统的硬连接功能（目录联接）。

目录联接

以管理员权限启动 CMD（命令提示符），输入 mklink 命令可以得知 mklink 的用法。

C:\WINDOWS\system32>mklink
创建符号链接。

MKLINK [[/D] | [/H] | [/J]] Link Target

        /D      创建目录符号链接。默认为文件
                符号链接。
        /H      创建硬链接而非符号链接。
        /J      创建目录联接。
        Link    指定新的符号链接名称。
        Target  指定新链接引用的路径
                (相对或绝对)。

我们本次要用 .NET/C# 代码实现的是 /J 目录联接。实现的效果像这样：

这些文件夹带有一个“快捷方式”的角标，似乎是另一些文件夹的快捷方式一样。但这些与快捷方式的区别在于，应用程序读取路径的时候，目录联接会成为路径的一部分。

比如在 D:\Walterlv\NuGet\ 中创建 debug 目录联接，目标设为 D:\Walterlv\DemoRepo\bin\Debug，那么，你在各种应用程序中使用以下两个路径将被视为同一个：

• D:\Walterlv\NuGet\debug\DemoRepo-1.0.0.nupkg
• D:\Walterlv\DemoRepo\bin\Debug\DemoRepo-1.0.0.nupkg

或者这种：

• D:\Walterlv\NuGet\debug\publish\
• D:\Walterlv\DemoRepo\bin\Debug\publish\

使用 .NET/C# 实现

本文的代码主要参考自 jeff.brown 在 Manipulating NTFS Junction Points in .NET - CodeProject 一文中所附带的源代码。

由于随时可能更新，所以你可以前往 GitHub 仓库打开此代码：

• walterlv.demo/JunctionPoint.cs at master · walterlv/walterlv.demo

使用 JunctionPoint

如果希望在代码中创建目录联接，则直接使用：

JunctionPoint.Create("walterlv.demo", @"D:\Developments", true);

后面的 true 指定如果目录联接存在，则会覆盖掉原来的目录联接。

参考资料

• windows - What the C# equivalent of “mklink /J”? - Stack Overflow
• Manipulating NTFS Junction Points in .NET - CodeProject
• Reparse Points - Windows applications - Microsoft Docs

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 程序无法触摸操作？我们一起来找原因和解决方法！

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

使用 .editorconfig 配置 .NET/C# 项目的代码分析规则的严重程度

随着 Visual Studio 2019 更新，在 Visual Studio 中编写代码的时候也带来了基于 Roslyn 的代码质量分析。有一些代码分析严重程度可能与团队约定的不一致，这时就需要配置规则的严重程度。另外如果是个人使用插件安装了分析器，也可以配置一些严重程度满足个人的喜好。

本文介绍使用 .editorconfig 文件来配置 .NET/C# 项目中，代码分析规则的严重性。可以是全局的，也可以每个项目有自己的配置。

生效范围与继承

.editorconfig 文件可以在你的项目中的任何地方，甚至是代码仓库之外。是按照文件夹结构来继承生效的。

比如我的项目结构是这样：

+ Walterlv.Demo
    + Core
        - .editorconfig
        - Foo.cs
    - .editorconfig
    - Program.cs

那么 Foo.cs 文件的规则严重性将受 Core 文件夹中的 .editorconfig 文件管理，如果有些规则不在此文件夹的 .editorconfig 里面，就会受外层 .editorconfig 管理。

另外，你甚至可以在整个代码仓库的外部文件夹放一个 .editorconfig 文件，这样，如果项目中没有对应的规则，那么外面文件夹中的 .editorconfig 规则就会生效，这相当于间接做了一个全局生效的规则集。

.editorconfig 中的内容

.editorconfig 中的分析器严重性内容就像下面这样：

[*.cs]

# CC0097: You have missing/unexistent parameters in Xml Docs
dotnet_diagnostic.CC0097.severity = error

# CA1031: Do not catch general exception types
dotnet_diagnostic.CA1031.severity = suggestion

# IDE0051: 删除未使用的私有成员
dotnet_diagnostic.IDE0051.severity = none

对于 C# 语言的规则，在 [*.cs] 区，每个规则格式是 dotnet_diagnostic.{DiagnosticId}.severity = {Severity}。

当然，我们不需要手工书写这个文件，了解它的格式只是为了出问题的时候不至于一脸懵逼。

配置严重程度

使用 Visual Studio 2019，配置规则严重性非常简单。当然，16.3 以上版本才这么简单，之前的版本步骤多一点。

在提示有问题的代码上按下重构快捷键（默认是 Ctrl + .），可以出现重构菜单，其中就有配置规则严重性的选项，直接选择即可自动添加到 .editorconfig 文件中。如果项目中没有 .editorconfig 文件，则会自动在解决方案同目录下创建一个新的。

对这部分快捷键不了解的话可以阅读：提高使用 Visual Studio 开发效率的键盘快捷键 - walterlv。

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

做 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）看它的代码，实际上是为了模态计数以及引发事件的，对模态的效果没有本质上的影响。

.NET/C# 检测电脑上安装的 .NET Framework 的版本

如果你希望知道某台计算机上安装了哪些版本的 .NET Framework，那么正好本文可以帮助你解决问题。

如何找到已安装的 .NET Framework

有的电脑的 .NET Framework 是自带的，有的是操作系统自带的。这样，你就不能通过控制面板的“卸载程序”去找到到底安装了哪个版本的 .NET Framework 了。

关于各个版本 Windows 10 上自带的 .NET Framework 版本，可以阅读 各个版本 Windows 10 系统中自带的 .NET Framework 版本 - walterlv。

而如果通过代码 Environment.Version 来获取 .NET 版本，实际上获取的是 CLR 的版本，详见 使用 PowerShell 获取 CLR 版本号 - walterlv。

这些版本号是不同的，详见 .NET Framework 4.x 程序到底运行在哪个 CLR 版本之上 - walterlv。

那么如何获取已安装的 .NET Framework 的版本呢？最靠谱的方法竟然是通过读取注册表。

注册表位置和含义

读取位置在这里：

计算机\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full\2052

而唯一准确能够判定 .NET Framework 版本的，只有里面的 Release 值。但可惜的是，这个值并不能直接看出来到底是 4.5 还是 4.8。我们需要有一张对应表。

我把它整理成了字典和注释，这样会比较容易理解每个编号对应的 .NET Framework 版本代号。

/// <summary>
/// 获取 .NET Framework 4.5 及以上版本的发行号与版本名称的对应关系。
/// 4.5 及以下版本没有这样的对应关系。
/// </summary>
private static readonly Dictionary<int, string> ReleaseToNameDictionary = new Dictionary<int, string>
{
    // .NET Framework 4.5
    { 378389, "4.5" },
    // .NET Framework 4.5.1（Windows 8.1 或 Windows Server 2012 R2 自带）
    { 378675, "4.5.1" },
    // .NET Framework 4.5.1（其他系统安装）
    { 378758, "4.5.1" },
    // .NET Framework 4.5.2
    { 379893, "4.5.2" },
    // .NET Framework 4.6（Windows 10 第一个版本 1507 自带）
    { 393295, "4.6" },
    // .NET Framework 4.6（其他系统安装）
    { 393297, "4.6" },
    // .NET Framework 4.6.1（Windows 10 十一月更新 1511 自带）
    { 394254, "4.6.1" },
    // .NET Framework 4.6.1（其他系统安装）
    { 394271, "4.6.1" },
    // .NET Framework 4.6.2（Windows 10 一周年更新 1607 和 Windows Server 2016 自带）
    { 394802, "4.6.2" },
    // .NET Framework 4.6.2（其他系统安装）
    { 394806, "4.6.2" },
    // .NET Framework 4.7（Windows 10 创造者更新 1703 自带）
    { 460798, "4.7" },
    // .NET Framework 4.7（其他系统安装）
    { 460805, "4.7" },
    // .NET Framework 4.7.1（Windows 10 秋季创造者更新 1709 和 Windows Server 1709 自带）
    { 461308, "4.7.1" },
    // .NET Framework 4.7.1（其他系统安装）
    { 461310, "4.7.1" },
    // .NET Framework 4.7.2（Windows 10 2018年四月更新 1803 和 Windows Server 1803 自带）
    { 461808, "4.7.2" },
    // .NET Framework 4.7.2（其他系统安装）
    { 461814, "4.7.2" },
    // .NET Framework 4.8（Windows 10 2019年五月更新 1903 自带）
    { 528040, "4.8" },
    // .NET Framework 4.8（其他系统安装）
    { 528049, "4.8" },
};

另外，还有一些值也是有意义的（只是不那么精确）：

• 主版本
  • 也就是可以共存的版本，比如 v3.5 系列和 v4 系列就是可以共存的，它们分别是就地更新的保持兼容的版本
• 发行版本名称
  • 完整版 Full 和精简版 Client
• 版本号
  • 比如 3.5.30729.4926 或者 4.7.02556
• 服务包版本
  • 古时候的微软喜欢用 SP1 SP2 来命名同一个版本的多次更新，这也就是那个年代的产物

它们分别在注册表的这些位置：

• 主版本
  • 计算机\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP 里项的名称
• 发行版本名称
  • 以上项里子项的名称
• 版本号
  • 以上项里的 Version 值
• 服务包版本
  • 以上项里的 SP 值

读取注册表

在上面已经梳理了读取注册表的位置之后，相信你可以很容易写出读取已安装 .NET Framework 版本的代码出来。

我已经将其做成了 NuGet 源代码包（使用 SourceYard 打包），你可以安装 NuGet 包来获得读取已安装 .NET Framework 版本的功能：

• NuGet Gallery - Walterlv.Environment.Source

或者在 GitHub 查看源代码：

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

只有一个类型——NdpInfo。

使用方法有两种。

第一种，获取当前计算机上所有已经安装的 .NET Framework 版本：

var allVersions = await NdpInfo.ReadFromRegistryAsync();

执行完成之后看看得到的字典 allVersions 如下：

字典里 Key 是不能共存的主版本，Value 是这个主版本里当前已经安装的具体版本信息。

如果直接使用 ToString()，是可以生成我们平时经常在各大文档或者社区使用的 .NET Framework 的名称。

第二种，获取当前已安装的最新的 .NET Framework 版本名称：

var currentVersion = NdpInfo.GetCurrentVersionName();

这可以直接获取到一个字符串，比如 .NET Framework 4.8。对于只是简单获取一下已安装名称而不用做更多处理的程序来说会比较方便。

Windows 系统上用 .NET/C# 查找所有窗口，并获得窗口的标题、位置、尺寸、最小化、可见性等各种状态

在 Windows 应用开发中，如果需要操作其他的窗口，那么可以使用 EnumWindows 这个 API 来枚举这些窗口。

你可以使用本文编写的一个类型，查找到所有窗口中你关心的信息。

需要使用的 API

枚举所有窗口仅需要使用到 EnumWindows，其中需要定义一个委托 WndEnumProc 作为传入参数的类型。

剩下的我们需要其他各种方法用于获取窗口的其他属性。

• GetParent 获取窗口的父窗口，这可以确认找到的窗口是否是顶层窗口。（关于顶层窗口，可以延伸 使用 SetParent 跨进程设置父子窗口时的一些问题（小心卡死） - walterlv。）
• IsWindowVisible 判断窗口是否可见
• GetWindowText 获取窗口标题
• GetClassName 获取窗口类名
• GetWindowRect 获取窗口位置和尺寸，为此我们还需要定义一个结构体 LPRECT

private delegate bool WndEnumProc(IntPtr hWnd, int lParam);

[DllImport("user32")]
private static extern bool EnumWindows(WndEnumProc lpEnumFunc, int lParam);

[DllImport("user32")]
private static extern IntPtr GetParent(IntPtr hWnd);

[DllImport("user32")]
private static extern bool IsWindowVisible(IntPtr hWnd);

[DllImport("user32")]
private static extern int GetWindowText(IntPtr hWnd, StringBuilder lptrString, int nMaxCount);

[DllImport("user32")]
private static extern int GetClassName(IntPtr hWnd, StringBuilder lpString, int nMaxCount);

[DllImport("user32")]
private static extern bool GetWindowRect(IntPtr hWnd, ref LPRECT rect);

[StructLayout(LayoutKind.Sequential)]
private readonly struct LPRECT
{
    public readonly int Left;
    public readonly int Top;
    public readonly int Right;
    public readonly int Bottom;
}

枚举所有窗口

我将以上 API 封装成 FindAll 函数，并提供过滤器可以给大家过滤众多的窗口使用。

比如，我写了下面一个简单的示例，可以输出当前可见的所有窗口以及其位置和尺寸：

using System;

namespace Walterlv.WindowDetector
{
    class Program
    {
        static void Main(string[] args)
        {
            var windows = WindowEnumerator.FindAll();
            for (int i = 0; i < windows.Count; i++)
            {
                var window = windows[i];
                Console.WriteLine($@"{i.ToString().PadLeft(3, ' ')}. {window.Title}
     {window.Bounds.X}, {window.Bounds.Y}, {window.Bounds.Width}, {window.Bounds.Height}");
            }
            Console.ReadLine();
        }
    }
}

这里的 FindAll 方法，我提供了一个默认参数，可以指定如何过滤所有枚举到的窗口。如果不指定，则会找可见的，包含标题的，没有最小化的窗口。如果你希望找一些看不见的窗口，可以自己写过滤条件。

什么都不要过滤的话，就传入 _ => true，意味着所有的窗口都会被枚举出来。

附源码

因为源代码会经常更新，所以建议在这里查看：

• walterlv.demo/Walterlv.WindowDetector/Walterlv.WindowDetector at master · walterlv/walterlv.demo

无法访问的话，可以看下面：

using System;
using System.Collections.Generic;
using System.Drawing;
using System.Runtime.InteropServices;
using System.Text;

namespace Walterlv.WindowDetector
{
    /// <summary>
    /// 包含枚举当前用户空间下所有窗口的方法。
    /// </summary>
    public class WindowEnumerator
    {
        /// <summary>
        /// 查找当前用户空间下所有符合条件的窗口。如果不指定条件，将仅查找可见窗口。
        /// </summary>
        /// <param name="match">过滤窗口的条件。如果设置为 null，将仅查找可见窗口。</param>
        /// <returns>找到的所有窗口信息。</returns>
        public static IReadOnlyList<WindowInfo> FindAll(Predicate<WindowInfo> match = null)
        {
            var windowList = new List<WindowInfo>();
            EnumWindows(OnWindowEnum, 0);
            return windowList.FindAll(match ?? DefaultPredicate);

            bool OnWindowEnum(IntPtr hWnd, int lparam)
            {
                // 仅查找顶层窗口。
                if (GetParent(hWnd) == IntPtr.Zero)
                {
                    // 获取窗口类名。
                    var lpString = new StringBuilder(512);
                    GetClassName(hWnd, lpString, lpString.Capacity);
                    var className = lpString.ToString();

                    // 获取窗口标题。
                    var lptrString = new StringBuilder(512);
                    GetWindowText(hWnd, lptrString, lptrString.Capacity);
                    var title = lptrString.ToString().Trim();

                    // 获取窗口可见性。
                    var isVisible = IsWindowVisible(hWnd);

                    // 获取窗口位置和尺寸。
                    LPRECT rect = default;
                    GetWindowRect(hWnd, ref rect);
                    var bounds = new Rectangle(rect.Left, rect.Top, rect.Right - rect.Left, rect.Bottom - rect.Top);

                    // 添加到已找到的窗口列表。
                    windowList.Add(new WindowInfo(hWnd, className, title, isVisible, bounds));
                }

                return true;
            }
        }

        /// <summary>
        /// 默认的查找窗口的过滤条件。可见 + 非最小化 + 包含窗口标题。
        /// </summary>
        private static readonly Predicate<WindowInfo> DefaultPredicate = x => x.IsVisible && !x.IsMinimized && x.Title.Length > 0;

        private delegate bool WndEnumProc(IntPtr hWnd, int lParam);

        [DllImport("user32")]
        private static extern bool EnumWindows(WndEnumProc lpEnumFunc, int lParam);

        [DllImport("user32")]
        private static extern IntPtr GetParent(IntPtr hWnd);

        [DllImport("user32")]
        private static extern bool IsWindowVisible(IntPtr hWnd);

        [DllImport("user32")]
        private static extern int GetWindowText(IntPtr hWnd, StringBuilder lptrString, int nMaxCount);

        [DllImport("user32")]
        private static extern int GetClassName(IntPtr hWnd, StringBuilder lpString, int nMaxCount);

        [DllImport("user32")]
        private static extern void SwitchToThisWindow(IntPtr hWnd, bool fAltTab);

        [DllImport("user32")]
        private static extern bool GetWindowRect(IntPtr hWnd, ref LPRECT rect);

        [StructLayout(LayoutKind.Sequential)]
        private readonly struct LPRECT
        {
            public readonly int Left;
            public readonly int Top;
            public readonly int Right;
            public readonly int Bottom;
        }
    }

    /// <summary>
    /// 获取 Win32 窗口的一些基本信息。
    /// </summary>
    public readonly struct WindowInfo
    {
        public WindowInfo(IntPtr hWnd, string className, string title, bool isVisible, Rectangle bounds) : this()
        {
            Hwnd = hWnd;
            ClassName = className;
            Title = title;
            IsVisible = isVisible;
            Bounds = bounds;
        }

        /// <summary>
        /// 获取窗口句柄。
        /// </summary>
        public IntPtr Hwnd { get; }

        /// <summary>
        /// 获取窗口类名。
        /// </summary>
        public string ClassName { get; }

        /// <summary>
        /// 获取窗口标题。
        /// </summary>
        public string Title { get; }

        /// <summary>
        /// 获取当前窗口是否可见。
        /// </summary>
        public bool IsVisible { get; }

        /// <summary>
        /// 获取窗口当前的位置和尺寸。
        /// </summary>
        public Rectangle Bounds { get; }

        /// <summary>
        /// 获取窗口当前是否是最小化的。
        /// </summary>
        public bool IsMinimized => Bounds.Left == -32000 && Bounds.Top == -32000;
    }
}

使用 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 激活，那么这个窗口中的逻辑焦点就会成为键盘焦点，另一个窗口当中的逻辑焦点保留，而键盘焦点则丢失。