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 如果要做差量编译,那么就不能直接使用原生的差量编译方案了。本文将介绍如何处理这样的情况。

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

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

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

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

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

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

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

将 async/await 异步代码转换为安全的不会死锁的同步代码(使用 PushFrame)

async/await 异步模型(即 TAP Task-based Asynchronous Pattern)出现以前,有大量的同步代码存在于代码库中,以至于这些代码全部迁移到 async/await 可能有些困难。这里就免不了将一部分异步代码修改为同步代码。然而传统的迁移方式存在或多或少的问题。本文将总结这些传统方法的坑,并推出一款异步转同步的新方法,解决传统方法的这些坑。

WPF/UWP 绑定中的 UpdateSourceTrigger

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

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

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

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