在 .NET 5 中生成 Microsoft Fakes 程序集

Question

我正在努力将 .NET 4.x 代码迁移到 .NET 5。单元测试项目广泛使用 Microsoft Fakes，最近通过 Visual Studio 2019 获得了 .NET 5 的正式实施。我有构建和在本地运行的单元测试，并开始在 AzureDevOps (On Prem) 中为项目设置 CI/CD 管道。我在本地和构建代理服务器上安装了 VS 2019 Enterprise

我的构建管道由 dotnet restore 和以下选项组成
-s https://api.nuget.org/v3/index.json -s "C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\"

我已将"C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\" 作为来源，因为我确定 Microsoft fakes 是由 VS 2019 企业版安装在此特定目录中的本地 nuget 包。

还原后运行两个 dotnet build 命令，并使用以下选项
--no-restore --configuration $(BuildConfiguration) /p:VersionPrefix=$(Build.BuildNumber) /p:AssemblyVersion=$(Build.BuildNumber) /p:GenerateProjectSpecificOutputFolder=True

我正在使用 2 个dotnet build 命令，因为我注意到我使用一个命令设置任务的方式导致测试项目在他们正在测试的项目之前构建并且不想花时间在找到一个 glob 模式来正确设置构建顺序。 （或者我误读了日志，无论哪种方式，我都在调试时将其拆分出来）

当为测试项目运行dotnet build 命令时，它会失败并显示消息 The type or namespace name 'Fakes' does not exist in the namespace (are you missing an assembly reference?)。这告诉我，我在测试项目中拥有的 Fakes 程序集不是由 dotnet build 生成的（或者至少是我目前拥有的选项）。为了生成 Fakes 程序集，我需要做什么？

其他：我在 azure dev ops 中使用 .NET CORE 任务的 1.x 版本。

更新 1

根据另一个论坛的建议，在我的本地工作站上运行相关的dotnet 命令也产生了同样的错误。应另一个人的要求，这是一个细分

dotnet build .sln --configuration Debug /p:GenerateProjectSpecificOutputFolder=True 在本地工作，但我意识到我仍然有上次在 Visual Studio 中构建 sln 的假程序集。于是尝试了

dotnet clean dotnet build .sln --configuration Debug /p:GenerateProjectSpecificOutputFolder=True 出现Fakes does not exist 错误。然后我尝试了

dotnet clean dotnet build Main.csproj --configuration Debug /p:GenerateProjectSpecificOutputFolder=True dotnet build Main.Tests.csproj --configuration Debug /p:GenerateProjectSpecificOutputFolder=True

Main.csproj 的构建成功，而 Main.Tests.csproj 的构建出错并显示 Fakes does not exist

dotnet clean dotnet restore dotnet build .sln --configuration Debug --no-restore /p:GenerateProjectSpecificOutputFolder=True 还会给出Fakes does not exist 错误

根据dotnet nuget list source，我正在从以下来源拉包

1.  nuget.org [Enabled]
    https://api.nuget.org/v3/index.json
2.  <Internal Nuget Feed 1> [Enabled]
      <Details Redacted>
3.  DevExpress 19.1 Local [Enabled]
  C:\Program Files (x86)\DevExpress 19.1\Components\System\Components\Packages
4.  Microsoft Visual Studio Offline Packages [Enabled]
    C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\
5.  <Internal Nuget Feed 2> [Enabled]
     <Details Redacted>

Answer 1

在重新阅读了一些 MS 文档中关于假货的次数超过我愿意承认的次数后，我终于找到了问题的主要原因。根据Using Microsoft Fakes in the CI部分中的this page，第一段中说

Since Microsoft Fakes requires Visual Studio Enterprise, the generation of Fakes Assemblies requires that you build your project using Visual Studio Build Task.

我还发现这也适用于运行使用 Microsoft Fakes 的单元测试。您不能在管道中使用dotnet test，而需要使用Visual Studio Test 任务。

这两项任务都必须使用 Visual Studio 2019 或更高版本。在我的情况下，这很复杂，因为我们使用的是 TFS 2017，即使您选择 Latest 作为 Visual Studio 版本，它也不会在这些管道任务中检测到 Visual Studio 2019。

为了解决这个问题，我不得不将 Visual Studio Build 更改为使用 MS Build 任务，以便指向 2019 年安装的 MS 版本。对于单元测试，我必须编写一个自定义的 powershell 脚本来调用正确版本的vstest.console.exe。更高版本的 Visual Studio Test 任务添加了一个字段来更改此路径，因此您不必使用 PowerShell 脚本。

如果您在查找 msbuild.exe 和 vstest.console.exe 的路径时需要帮助，可以在构建服务器上打开 Visual Studio 2019 Developer Prompt 并运行 where msbuild 和 where vstest.console.exe 获取您需要在管道中使用的路径。

对于发布，如果添加 --no-build 参数，您仍然可以使用 dotnet publish。如果您使用像**/*.csproj 这样的通配符模式，您还需要从发布命令中排除具有模式!**/f.csproj 的项目。 f.csproj 文件是在构建过程中生成的假货，如果发布任务发现它们带有类似于

的消息，则会出错

无法复制文件 “obj\Debug\net5.0\Fakes\sdc\b\net5.0\System.Data.Common.5.0.0.0.Fakes.deps.json” 因为没有找到。 [obj\Debug\net5.0\Fakes\sdc\f.csproj]