Fake 5 提供.NET Core 支持

Fake 5 在推出预览版的数个月后于近期发布。该新版本的.NET 应用构建工具重写了内核，做了一些内部改进，并推出了一些新特性。为更好地了解新版本中的改进和特性，InfoQ 采访了 Fake 的维护者 Matthias Dittrich。

InfoQ：是什么促使您推出 Fake 5 版本？

Matthias Dittrich：回顾历史，我感觉使用 Fake 曾是一个巨大的负担，尤其是使用推荐的方法时。因为开发人员必须要学会 Paket、FAKE，并引入build.fsx、paket.dependencies、paket.lock等多个全局文件，进而 Paket 才能另外创建多个文件夹（例如paket-files、packages和.paket等），Fake 才能创建.fake文件夹。

这样的架构完全可用，因为所有这些操作背后都有其合理的原因。但这对于一些小型项目或简单的脚本而言无疑过于繁琐。我认为这是妨碍人们采纳 Fake 的一个主要考虑。

在.NET Core 推出之后，我们得以抛弃过去对.NET 的所有认知。开发人员可以发布一个独立的应用，无需依赖于任何已安装的.NET Framework。我感觉到，当前正是重新考虑已有方法的一个很好机会。我开始逐步引导并使用.NET Core 移植去实现 Fake。当然，我们最终也必须要这样做。

由此，发布 Fake 5 的目标主要上是解决上面提及的问题，允许开发人员选择性退出（opt-out）到一种更为简单的工作流。此外，Fake 5 还要解决其它一些长期以来一直存在的突出问题，例如 API 的清理和统一，以及分解为更小的模块。

有人曾为单一项目贡献了一种称为FakeLib的新功能，该软件库已经发展了 5 到 10 年！可能在人们毫不知情的情况下，我们已经蓄势待发。

另一方面，这意味着任何人在每次构建时都需要做全部关联项下载。其中一些关联项，我们并不知道如何在不破坏整个生态系统的情况下进行修复。这个问题应该如何解决？我们现在另辟蹊径了。

InfoQ：现在开发人员可以通过创建自定义模块扩展 Fake。您能详细介绍一下其工作机制吗？

Dittrich： 当然。事实上，这（从用户角度看）非常简单。开发人员所需要做的，仅是在任一 NuGet 源上发布一个.NET（或者 C#、F#等）软件库，并在自己构建脚本的头部使用 Paket 语法引用该软件库。

唯一要满足的需求，就是该软件库应兼容 NetStandard 2.0。

举个例子。如果我安装了.NET SDK、创建了一个名为testfakelib的新文件夹、执行了dotnet new classlib && dotnet pack命令，并上传bin/Debug/testfakelib.nupkg文件到 NuGet，那么这时我就完成了准备工作。

技术上讲，我们在后台使用 Paket 完成繁琐的传递依赖关系解析，并用于发现 Fake/F#脚本编译和运行所需的正确 dll 文件。虽然这有点过分简化了，但至少不会让用户百无聊赖。

InfoQ：该版本的主要特性或改进是什么？

Dittrich：在我看来，Fake 5 的最主要特性如下：

• 无论开发人员当前使用何种环境，无论他们选择了何种 Fake 引导或安装方式，上手工作都更为容易。
• FAKE 现在更适用于脚本和小型自动化（我们进一步“扩展”了构建功能）。
• 开发人员现在可以引入更广泛的 NuGet 生态系统，实现构建的扩展，也易于自身的扩展。

但是做出选择依然并非易事。例如，大量来自于社区的帮助正在实现 API 的清理和模块化。我认为，这些工作的结果值得称赞。

问题在于，我们不可能从一开始就做到完美无瑕。

借助于模块化系统，我们希望能创建更好的模块改进，并在不破坏任何系统的情况下隔离旧模块。

InfoQ：为实现支持.NET Core，您做了哪些改进？

Dittrich：事实上，我并不认为我们必须做的大量工作，仅是为了支持.NET Core。我们只是利用了现有的机会。技术上讲，尤其是自 NetStandard 2.0 推出后，我们大概仅是重新编译了大部分代码。其中的工作乏善可陈。

Fake 官方网站上提供了更多的详细信息，其中包括 Fake 5 发行说明。

查看英文原文： Fake 5 Brings .NET Core Support