我正在使用 TeamCity 中的 MSBuild 运行程序来构建 ASP.net Web API 并运行单元测试。一切正常，直到我升级到“Microsoft Build Tools 2017 15.7.2”。

msbuild 突然从“C:\Program Files (x86)\ISS\Microsoft Web Deploy V3”或“C:\Program Files\ISS”复制旧版本的 Newtonsoft.Json.dll(版本 6.0.4.17603)\Microsoft Web Deploy V3”在构建解决方案时添加到输出文件夹。所有项目都使用 NuGet 引用 9.0.1 版本。

在构建运行时监视输出文件夹，我可以看到 .dll 在 6.0.4 和 9.0.1 之间来回切换，直到构建结束，而 6.0.4 版本仍然存在。

我找到了 this question当我将 Web 部署文件夹中的 Newtonsoft.Json.dll 文件重命名为 Newtonsoft.Json_old.dll”时，msbuild 没有替换我的 9.0.1 版本并且一切正常。

我已检查所有引用 Newtonsoft.Json 的项目都引用 9.0.1 版本并在 .csproj 文件中使用正确的提示路径。

有没有人知道如何解决这个问题？我的解决方案似乎更像是一种解决方法，我想知道为什么 msbuild 首先要复制此文件。

最佳答案

总结

当 MSBuild 解析程序集时，它会在一些非常奇怪的目录中搜索，包括 Web Deploy 文件夹，具体取决于您安装的内容。根据 MSBuild 引用，我认为这是遗留行为。您可以使用项目文件中定义的 MSBuild 属性来阻止它执行此操作。

在受影响的项目文件中，找到以下行:

<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />

并在下面添加:

<PropertyGroup>
    <AssemblySearchPaths>$(AssemblySearchPaths.Replace('{AssemblyFolders}', '').Split(';'))</AssemblySearchPaths>
</PropertyGroup>

这将导致 MSBuild 在解析程序集时不再查找有问题的文件夹。

全文

当我们迁移到 Visual Studio 2019 时，我的团队遇到了类似的问题。我们的一些项目仍然以 .NET Framework 4.0 为目标，并且在我们的构建代理上安装 Visual Studio 2019 后，我们开始遇到一个神秘的项目错误引用了我们的一些核心库:

The primary reference "OurCoreLibrary, Version=3.4.2.0, Culture=neutral, PublicKeyToken=xxxxxxxxxxxxxxxx, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the assembly "Newtonsoft.Json, Version=9.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed" which was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.0".

将项目切换到目标 4.5 后问题就消失了，但由于我不会在这里详述的原因，我们无法对每个受影响的项目都这样做，所以我决定深入挖掘一下。

事实证明，您的问题让我们对正在发生的事情有了一些了解。我们引用的 Newtonsoft.Json 版本与“C:\Program Files (x86)\IIS\Microsoft Web Deploy V3”中的版本匹配，当我删除该文件时，构建成功。

我们的具体问题是 Web Deploy 文件夹中的 Newtonsoft.Json 副本是同一版本 (9.0.0.0)，但框架错误(4.5 而不是 4.0)，无论出于何种原因，解析逻辑都不会检查目标框架，导致构建时不匹配。更新到 VS2019 涉及更新 Web Deploy，这也将 Newtonsoft.Json 的副本更新到 9.0.0.0，导致我们发生冲突。

为了了解为什么甚至开始查看该程序集，我将 MSBuild 项目构建输出详细程度设置为诊断并查看发生了什么。搜索有问题的路径表明，在 ResolveAssemblyReferences 任务中，MSBuild 正在通过一些意想不到的地方来寻找匹配项:

1>          For SearchPath "{AssemblyFolders}". (TaskId:9)
1>          Considered "C:\Program Files (x86)\Microsoft.NET\ADOMD.NET\140\OurCoreLibrary.winmd", but it didn't exist. (TaskId:9)
1>          Considered "C:\Program Files (x86)\Microsoft.NET\ADOMD.NET\140\OurCoreLibrary.dll", but it didn't exist. (TaskId:9)
1>          Considered "C:\Program Files (x86)\Microsoft.NET\ADOMD.NET\140\OurCoreLibrary.exe", but it didn't exist. (TaskId:9)
1>          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0\OurCoreLibrary.winmd", but it didn't exist. (TaskId:9)
1>          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0\OurCoreLibrary.dll", but it didn't exist. (TaskId:9)
1>          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0\OurCoreLibrary.exe", but it didn't exist. (TaskId:9)
1>          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\OurCoreLibrary.winmd", but it didn't exist. (TaskId:9)
1>          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\OurCoreLibrary.dll", but it didn't exist. (TaskId:9)
1>          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\OurCoreLibrary.exe", but it didn't exist. (TaskId:9)
1>          Considered "C:\Program Files\IIS\Microsoft Web Deploy V3\OurCoreLibrary.winmd", but it didn't exist. (TaskId:9)
1>          Considered "C:\Program Files\IIS\Microsoft Web Deploy V3\OurCoreLibrary.dll", but it didn't exist. (TaskId:9)
1>          Considered "C:\Program Files\IIS\Microsoft Web Deploy V3\OurCoreLibrary.exe", but it didn't exist. (TaskId:9)
1>          Considered "C:\Program Files (x86)\Microsoft SQL Server\140\SDK\Assemblies\OurCoreLibrary.winmd", but it didn't exist. (TaskId:9)
1>          Considered "C:\Program Files (x86)\Microsoft SQL Server\140\SDK\Assemblies\OurCoreLibrary.dll", but it didn't exist. (TaskId:9)
1>          Considered "C:\Program Files (x86)\Microsoft SQL Server\140\SDK\Assemblies\OurCoreLibrary.exe", but it didn't exist. (TaskId:9)

进一步挖掘表明，搜索的路径作为 AssemblySearchPaths 传入，定义在 Microsoft.Common.CurrentVersion.targets 中:

<AssemblySearchPaths Condition=" '$(AssemblySearchPaths)' == ''">
  {CandidateAssemblyFiles};
  $(ReferencePath);
  {HintPathFromItem};
  {TargetFrameworkDirectory};
  $(AssemblyFoldersConfigFileSearchPath)
  {Registry:$(FrameworkRegistryBase),$(TargetFrameworkVersion),$(AssemblyFoldersSuffix)$(AssemblyFoldersExConditions)};
  {AssemblyFolders};
  {GAC};
  {RawFileName};
  $(OutDir)
</AssemblySearchPaths>

根据MSBuild Task Reference for the ResolveAssemblyReferences task , SearchPaths 参数定义为:

Specifies the directories or special locations that are searched to find the files on disk that represent the assemblies. The order in which the search paths are listed is important. For each assembly, the list of paths is searched from left to right. When a file that represents the assembly is found, that search stops and the search for the next assembly starts.

...它定义了一些特殊常量，包括我们的 friend {AssemblyFolders}:

• {AssemblyFolders}: Specifies the task will use the Visual Studio.NET 2003 finding-assemblies-from-registry scheme.

因为目录是按顺序检查的，您可能希望 {HintPathFromItem} 优先，在大多数情况下确实如此。但是，如果您的依赖项依赖于旧版本的 Newtonsoft.Json，则不会有 HintPath 该版本，因此它将继续存在，直到它解决。

Later on in Microsoft.Common.CurrentVersion.targets我们可以看到有些情况下这个常量被显式删除，这就是上面答案的来源:

<PropertyGroup Condition="'$(_TargetFrameworkDirectories)' == '' and '$(AssemblySearchPaths)' != '' and '$(RemoveAssemblyFoldersIfNoTargetFramework)' == 'true'">
  <AssemblySearchPaths>$(AssemblySearchPaths.Replace('{AssemblyFolders}', '').Split(';'))</AssemblySearchPaths>
</PropertyGroup>

删除此常量会从考虑中删除有问题的文件夹，老实说，我想不出我希望程序集隐式解析为 Newtonsoft.Json 在 Web 部署中闲逛的任何版本的情况，或者SQL Server SDK 文件夹。话虽这么说，但我确信在某些情况下关闭此功能会导致某些人出现问题，因此请记住这一点。

关于c# - MSBuild 正在用旧版本替换 Newtonsoft.Json.dll，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50638711/