Fake 5提供.NET Core支持

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

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章