嗯,dnx 项目中没有 .csproj,dnu 构建项目所需的一切都包含在project.json 中。有一个 xproj 文件,但您可以忽略它。微软终于决定看到曙光,并将 xproj 仅用于 VS 特定的“东西”,并将与 IDE 无关的项目详细信息放在 project.json 中。
所以要构建一个 dnx 项目,您只需要正确版本的 dnx 和项目源代码即可。现在 AFAIK 没有开箱即用的解决方案,但一切都是用命令行命令完成的,所以编写脚本应该很容易。这完全取决于您要构建的解决方案的稳健程度。
要从命令行构建一个 dnx 项目(假设您安装了正确的 dnx 并将其设置为活动状态),只需两个命令。 dnu restore 运行依赖项检查,并且 dnu(dnx 的一部分)具有内置的 nuget 客户端,因此它会在需要时伸出并获取依赖项。 dnu build 运行实际编译。
所以 cd 到项目根目录(包含 project.json)并运行 dnu restore 然后 dnu build。
如果您需要动态支持不同的 dnx 版本,它会变得更加复杂。请记住,dnx 版本由运行时(coreclr 或 clr)、架构(x86、x64 等)和版本号标识。因此,如果您只针对说 x64 构建在 clr(完整的 .net 运行时)上消除了两个变量,但是如果项目需要比构建服务器上安装的运行时版本更新的运行时会发生什么?例如,您在构建服务器上安装(手动使用 dnvm)dnx-clr-win-x64.1.0.0-beta4,但在未来某个时候,开发人员需要 dnx-clr-win-x64.1.0.0- beta6-1200 来解决一个错误。
简单的解决方案是根据需要安装新的运行时版本,并针对所需的最新版本构建所有项目。这并不像最初听起来那么糟糕。一旦 dnx 退出测试版,对运行时的更改应该很少。请记住,运行时是非常低级的代码和非托管 dll。它是 BCL 位于其之上的引导存根。希望给定操作系统、架构和运行时的 dnx 不会有太多变化。
要获得更强大的解决方案,您可以使用脚本来查找项目所需的运行时版本。它位于解决方案级别global.json。然后脚本可以使用dnvm list 来确定它是否安装了该运行时。如果没有,则使用dnvm install 或dnvm upgrade 安装所需的版本。在开始构建之前,它将使用命令dnvm use 激活正确的运行时,然后继续使用dnu restore 和dnu build。
老实说,我希望出现一些非常强大的解决方案。任务运行器(gulp、grunt 等)是 .NET 5 中的一等公民。您的工作流程很可能涉及用于客户端依赖解析的 bower、npm、grunt/gulp 和一些用于缩小 js 文件之类的任务包。构建服务器也将需要所有这些,因此将构建任务作为 grunt 或 gulp 包似乎非常合适。