Fake 5提供.NET Core支持

语言开发

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

作者： Pierre-Luc Maheu

正文：

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