ell*_*t-j 3 c# microsoft-fakes visual-studio-2019 .net-5
我正在致力于将 .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命令,因为我注意到使用一个命令设置任务的方式导致测试项目在他们正在测试的项目之前构建,并且不想花时间寻找要设置的全局模式构建顺序正确。(或者我误读了日志,无论哪种方式,我在调试时都将其分开以便清楚)
当该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 中使用 1.x 版本的 .NET CORE 任务。
经过另一个论坛的建议后,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>
Run Code Online (Sandbox Code Playgroud)
在重新阅读了一些关于假货的微软文档之后,我终于找到了问题的主要原因。根据本页Using Microsoft Fakes in the CI第一段中所述的部分
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 开发人员提示符并运行
where msbuild ,where vstest.console.exe以获取需要在管道中使用的路径。
dotnet publish对于发布,如果添加参数,您仍然可以使用--no-build。!**/f.csproj如果您使用类似的通配符模式,您还需要从发布命令中排除具有该模式的项目**/*.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]