让 MSBuild Target 支持 Clean

我们有时候会使用解决方案的清理（Clean）功能来解决一些项目编译过程中非常诡异的问题。这通常是一些 Target 生成了一些错误的中间文件，但又不知道到底是哪里错了。

我们自己编写 Target 的时候，也可能会遇到这样的问题，所以让我们自己的 Target 也能支持 Clean 可以在遇到诡异问题的时候，用户可以自己通过清理解决方案来消除错误。

出于迁移项目的考虑，GitHub 中 Fork 出来的项目，如何与原项目断开 Fork 关系？

如果需要为 GitHub 上的项目做贡献，我们通常会 Fork 到自己的名称空间下。在推送代码之后添加 pull request 时，GitHub 会自动为我们跨仓库建立 pull request 的连接，非常方便。但是，如果 Fork 是出于项目的迁移，例如从个人名下迁移到某个组织下或者反过来，那么这种自动的 pull request 的设置就很影响效率了。

那么这种情况如何处理呢？如何断开 Fork 连接呢？

C# 中委托实例的命名规则

我们知道一个类中的属性应该用名词或名词性短语，方法用动词或动宾短语；但是委托的实例却似乎有一些游离。因为在 .NET 中委托代表的是一个动作，既可以把它看作是名词，也可以看作是动词。在用法上，既可以像属性和变量一样被各种传递，也可以像一个方法一样被调用。

那么委托实例的命名，应该遵循属性和变量的命名，还是遵循方法的命名呢？

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 来避免性能的急剧降低。