Write a MSBuild Target to detect whether the project is rebuilding or not

MSBuild or the dotnet build command both supports Incremental Building for compiling performance. You can read How to: Build Incrementally - Visual Studio - Microsoft Docs to lean more about incremental building. When a target supports increment building and the project is rebuilding for the moment, the Target will not execute. So if it affects followed other Targets, it cannot be set to incremental building.

But how can I detect a incremental building behavior and do something different things if my Target affects followed other Targets? In this post, I’ll talk about that.

编写 Target 检测 MSBuild / dotnet build 此次编译是否是差量编译

MSBuild 或 Roslyn 编译项目时均支持差量编译，毕竟为了性能。我在 每次都要重新编译？太慢！让跨平台的 MSBuild/dotnet build 的 Target 支持差量编译 一文中介绍了如何使一个 Target 支持差量编译。在那篇文章中我说到差量编译会导致 Target 不执行；也就是说，如果一个 Target 对后续的编译会产生影响，那么一定不能设置为差量编译。

不过，真的会写出一些非常耗时的 Target，但是它会对后续的编译产生影响。这些 Target 如果要做差量编译，那么就不能直接使用原生的差量编译方案了。本文将介绍如何处理这样的情况。

在 Roslyn 分析语法树时添加条件编译符号的支持

我们在代码中会写 #if DEBUG 或者 [Conditional("DEBUG")] 来使用已经定义好的条件编译符号。而定义条件编译符号可以在代码中使用 #define WALTERLV 来实现，也可以通过在项目属性中设置条件编译符号（Conditional Compilation Symbols）来实现。

然而如果我们没有做任何特殊处理，那么使用 Roslyn 分析使用了条件编译符号的源码时，就会无法识别这些源码。

.NET 除了用 Task 之外，如何自己写一个可以 await 的对象？

.NET 中的 async / await 写异步代码用起来真的很爽，就像写同步一样。我们可以在各种各样的异步代码中看到 Task 返回值，这样大家便可以使用 await 等待这个方法。不过，有时需要写一些特别的异步方法，这时需要自己来实现一个可以异步等待的对象。

本文将讲述如何实现一个可等待对象，一个自定义的 Awaiter。

定义一组抽象的 Awaiter 的实现接口，你下次写自己的 await 可等待对象时将更加方便

我在几篇文章中都说到了在 .NET 中自己实现 Awaiter 情况。async / await 写异步代码用起来真的很爽，就像写同步一样。然而实现 Awaiter 没有现成的接口，它需要你按照编译器的要求为你的类型添加一些具有特定名称的属性和方法。然而没有接口的帮助，我们编写起来就很难获得工具（如 ReSharper）自动生成代码的支持。

本文将分享我提取的自己实现 Awaiter 的接口。你只需要实现这些接口当中的 2 个，就能正确实现一个 Awaitable 和 Awaiter。

了解 .NET 的默认 TaskScheduler 和线程池（ThreadPool）设置，避免让 Task.Run 的性能急剧降低

.NET Framework 4.5 开始引入 Task.Run，它可以很方便的帮助我们使用 async / await 语法，同时还使用线程池来帮助我们管理线程。以至于我们编写异步代码可以像编写同步代码一样方便。

不过，如果滥用，也可能导致应用的性能急剧下降。本文将说明在默认线程池配置（ThreadPoolTaskScheduler）的情况下，应该如何使用 Task.Run 来避免性能的急剧降低。

在 WPF/UWP 中实现一个可以用 await 异步等待 UI 交互操作的 Awaiter

.NET 和 C# 共同给我们带来的 async/await 异步编程模型（TAP）用起来真的很爽。为了实现异步等待，我们只需要在一切能够能够异步等待的方法前面加上 await 即可。能够异步等待的最常见的类型莫过于 Task，但也有一些其他类型。即便有些耗时操作没有返回可等待的类型，我们也可以用一句 Task.Run(action) 来包装（同步转异步 - 林德熙 中也有说明）；不过副作用就是 Run 里面的方法在后台线程执行了（谁知道这是好处呢还是坏处呢 ^_^）。

问题就在于，有些“耗时”操作根本就无法放入后台线程，典型的莫过于“耗时”的 UI 操作。本文将通过实现一个适用于 UI 的可等待类型来解决这种 UI 的“耗时”等待问题。

.NET 编写一个可以异步等待循环中任何一个部分的 Awaiter

林德熙 小伙伴希望保存一个文件，并且希望如果出错了也要不断地重试。然而我认为如果一直错误则应该对外抛出异常让调用者知道为什么会一直错误。

这似乎是一个矛盾的要求。然而最终我想到了一个办法：让重试一直进行下去，谁需要关心异常谁就去 catch 异常，不需要关心异常的模块则跟着一直重试直到成功。

我们通过编写一个自己的 Awaiter 来实现，本文将说明其思路和最终实现的代码。

.NET 中使用 TaskCompletionSource 作为线程同步互斥或异步操作的事件

你可以使用临界区（Critical Section）、互斥量（Mutex）、信号量（Semaphores）和事件（Event）来处理线程同步。然而，在编写一些异步处理函数，尤其是还有 async 和 await 使用的时候，还有一些更方便的类型可以用来处理线程同步。

使用 TaskCompletionSource，你可以轻松地编写既可以异步等待，又可以同步等待的代码来。

文件和文件夹不存在的时候，FileSystemWatcher 监听不到文件的改变？如果递归地监听就可以了

当你需要监视文件或文件夹的改变的时候，使用 FileSystemWatcher 便可以完成。不过，FileSystemWatcher 对文件夹的监视要求文件夹必须存在，否则会产生错误“无效路径”。

那么，如果文件或文件夹不存在的时候可以怎么监视文件的改变呢？更麻烦的是如果顶层很多级文件夹都不存在，怎么能监视呢？本文将告诉你方法。

本文的代码适用于 .NET Framework 和 .NET Core，同时不需要任何第三方依赖。

WPF/UWP 绑定中的 UpdateSourceTrigger

在开发 markdown-mail 时遇到了一些诡异的情况。代码是这么写的：

<TextBox Text="{Binding Text, Mode=TwoWay}"/>

然而在 TextChanged 事件之后延时执行了一些操作时，从 ViewModel 里拿到的值却始终是旧的。

阅读本文将了解其原因和解决办法。