我在这里快疯了，希望这只是我忽略了的事情。
我经历了间歇性的FileLoadExceptions，在部署后即使代码更改没有改变任何程序集引用也会出现。
最近遇到一个例子，由于无法找到System.IO.Compression版本4.2.0.0，我看到了一个FileLoadException。
在所有情况下，我们都引用System.IO.Compression nuget包，版本4.3.0。
查看我们解决方案中的两个项目，我注意到一些非常奇怪的事情。 ProjectA引用ProjectB。
ProjectA在它的packages.config文件中有如下的引用:
当我查看
再次强调，
所以我的问题是，为什么Visual Studio从一个未被任何项目（直接）引用的位置拉取
另外，在本地我使用的是当前版本的RC Visual Studio 2019，而我们的构建代理（Azure DevOps Pipelines）正在使用Visual Studio 2017。
在运行时，我们发现上述的异常被记录下来，并且我们创建ZIP文件的处理失败了。
更新
除上述内容外，我还进行了一些额外的研究，发现有一个绑定重定向指向这个程序集的
仍需要理解我们如何进入这种状态，以及
我经历了间歇性的FileLoadExceptions，在部署后即使代码更改没有改变任何程序集引用也会出现。
最近遇到一个例子，由于无法找到System.IO.Compression版本4.2.0.0，我看到了一个FileLoadException。
在所有情况下，我们都引用System.IO.Compression nuget包，版本4.3.0。
查看我们解决方案中的两个项目，我注意到一些非常奇怪的事情。 ProjectA引用ProjectB。
ProjectA在它的packages.config文件中有如下的引用:
<package id="System.IO.Compression" version="4.3.0" targetFramework="net462" />
ProjectB 在其 package.config 文件中有以下引用：
<package id="System.IO.Compression" version="4.3.0" targetFramework="net462" />
当我查看
*.csproj文件时，我看到了这个：
ProjectA:<Reference Include="System.IO.Compression, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
<HintPath>..\packages\System.IO.Compression.4.3.0\lib\net46\System.IO.Compression.dll</HintPath>
</Reference>`
ProjectB:
<Reference Include="System.IO.Compression, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
<HintPath>..\packages\System.IO.Compression.4.3.0\lib\net46\System.IO.Compression.dll</HintPath>
</Reference>`
很好，我们在这两种情况下都指向了同一个程序集。
然而，当我在解决方案资源管理器中查看引用的文件时，我看到了这个：
ProjectA:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.IO.Compression.dll，更重要的是它的版本是4.2.0.0，而不是NuGet包文件夹中的版本。
:
4.1.2.0。再次强调，
ProjectA引用了ProjectB，两者都有一个绑定重定向，执行以下操作：<dependentAssembly>
<assemblyIdentity name="System.IO.Compression" publicKeyToken="b77a5c561934e089" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.1.2.0" newVersion="4.1.2.0" />
</dependentAssembly>`
所以我的问题是，为什么Visual Studio从一个未被任何项目（直接）引用的位置拉取
System.IO.Compression的版本？我应该怎么做才能解决这个问题？另外，在本地我使用的是当前版本的RC Visual Studio 2019，而我们的构建代理（Azure DevOps Pipelines）正在使用Visual Studio 2017。
在运行时，我们发现上述的异常被记录下来，并且我们创建ZIP文件的处理失败了。
更新
除上述内容外，我还进行了一些额外的研究，发现有一个绑定重定向指向这个程序集的
4.2.0.0版本。我手动将它降级到4.1.2.0，并再次部署到我们的测试环境中并进行一些额外的健康检查，以查看进展如何。仍需要理解我们如何进入这种状态，以及
csproj所指向的内容与Solution Explorer中所看到的内容之间的差异。