Fake 5 提供.NET Core 支持

  • Pierre-Luc Maheu
  • 盖磊

2018 年 6 月 24 日

话题:.NETDevOps语言 & 开发

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

InfoQ:是什么促使您推出 Fake 5 版本?

Matthias Dittrich:回顾历史,我感觉使用 Fake 曾是一个巨大的负担,尤其是使用推荐的方法时。因为开发人员必须要学会 Paket、FAKE,并引入build.fsxpaket.dependenciespaket.lock等多个全局文件,进而 Paket 才能另外创建多个文件夹(例如paket-filespackages.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

.NETDevOps语言 & 开发