我正在尝试在我们的构建服务器上构建一个 VS2015 ASP.NET v5 Web 应用程序(基本上,在 Visual Studio 之外)。我们现有的脚本只是使用 csproj 文件调用 msbuild,但是通过这个项目,我得到:
项目文件为空
在 Visual Studio 之外“构建”这些新 Web 应用的“故事”是什么?我相信他们仍然可以针对 .NET 4.5(我希望如此,因为我们不会很快升级 Web 服务器)所以假设这是可能的。
我正在尝试在我们的构建服务器上构建一个 VS2015 ASP.NET v5 Web 应用程序(基本上,在 Visual Studio 之外)。我们现有的脚本只是使用 csproj 文件调用 msbuild,但是通过这个项目,我得到:
项目文件为空
在 Visual Studio 之外“构建”这些新 Web 应用的“故事”是什么?我相信他们仍然可以针对 .NET 4.5(我希望如此,因为我们不会很快升级 Web 服务器)所以假设这是可能的。
嗯,dnx 项目中没有 .csproj,dnu 构建项目所需的一切都包含在 .csproj 中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
and dnu build
。
老实说,我希望出现一些非常强大的解决方案。任务运行程序(gulp、grunt 等)是 .NET 5 中的一等公民。您的工作流程很可能涉及用于客户端依赖解析的 bower、npm、grunt/gulp 和一些用于缩小 js 文件之类的任务包。构建服务器也将需要所有这些,因此将构建任务作为 grunt 或 gulp 包似乎非常合适。