核心ASP.NET Project Azure构建管道

Question

我有一个简单的解决方案，其中包含两个项目，我希望它通过azure构建管道。一个项目是纯类文件，这些文件将生成DLL，但该代码不是同一文件夹中的GIT存储库。另一个项目是ASP.NET项目，我已经在管道中进行了配置。当我尝试构建项目时，它给我一个错误，如下所示：

  

MSBUILD：错误MSB1011：指定要使用的项目或解决方案文件   因为此文件夹包含多个项目或解决方案文件。   [错误] Cmd.exe退出，代码为“ 1”。

Yaml文件

# ASP.NET Core
# Build and test ASP.NET Core projects targeting .NET Core.
# Add steps that run tests, create a NuGet package, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core

trigger:
- master

pool:
  name: 'buildserver'

variables:
  buildConfiguration: 'Release'

steps:
- script: dotnet build --configuration $(buildConfiguration)
  displayName: 'dotnet build $(buildConfiguration)'

Answer 1

错误是要求您识别b / c的.sln或.csproj（或其他proj类型）文件dotnet不知道您要做什么。

我倾向于将变量用于此类操作，因为我经常在其他任务中使用解决方案名称。

示例：

trigger:
- master

pool:
  name: 'buildserver'

variables:
  buildConfiguration: 'Release'
  slnName: 'mySol'
  solution: 'some/dir/$(slnName).sln'

steps:
- script: dotnet build $(solution) --configuration $(buildConfiguration)
  displayName: 'dotnet build $(buildConfiguration)'

.csproj示例：

具有如下的存储库（和解决方案）结构：
（这是您不清楚的部分）

myRepo
|--.git
|--src
   |--proj1
   |  |--proj1.csproj
   |
   |--proj2
   |  |--proj2.csproj
   |
   |--mySol.sln

您只需调用要构建管道的.csproj文件即可。

trigger:
- master

pool:
  name: 'buildserver'

variables:
  buildConfiguration: 'Release'
  projName: 'proj1'
  project: 'src/$(projName)/$(projName).csproj'

steps:
- script: dotnet build $(project) --configuration $(buildConfiguration)
  displayName: 'dotnet build $(buildConfiguration)'

在上述示例中，您无需指定.sln或.csproj，因为每个潜在的构建目标都位于其自己的目录中，如果您使用dotnet cli从$pwd中进行搜索不要给它一个价值。因此，如果您的管道在仓库的根目录下工作（默认行为），则dotnet应该首先找到.sln文件并进行构建。

但是

如果您的目录结构如下所示，则需要指定：

myRepo
|--.git
|--src
   |--proj1.csproj
   |--class1.cs
   |--class2.cs
   |--proj2
   |  |--proj2.csproj
   |  |--class1.cs
   |
   |--mySol.sln

在上面的dotnet中，您不知道要构建mySol.sln还是proj1.csproj，因此指示要构建的文件应该可以解决您的问题，但是我建议您进行重组您的存储库。

如果proj2不在myRepo内居住

并且是proj1的依赖项，那么您将需要在管道中执行其他一些杂技（例如，手动git repo克隆）以获取该项目及其所需的文件。如果是这种情况，我会强烈建议，将proj2视为完全独立的产品，并将其交付给那些通过NuGet或其他包裹递送方法依赖它。