【问题标题】:Visual Studio 2017 doesn't resolve a specific reference correctlyVisual Studio 2017 无法正确解析特定引用
【发布时间】:2018-12-28 14:35:39
【问题描述】:

我的解决方案中有几个项目通过 nuget 引用 System.ValueTuple.dll。所有这些项目的程序集路径都定义为相同,但 Visual Studio 2017 以不同方式解决它。这导致它一遍又一遍地构建大部分项目,尽管没有任何变化。

下面是如何在项目文件中定义引用的示例(同样,所有项目都相同):

<Reference Include="System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL">
  <HintPath>..\..\..\..\packages\System.ValueTuple.4.4.0\lib\net461\System.ValueTuple.dll</HintPath>
  <Private>True</Private>
</Reference>

这是我得到的消息,当 Visual Studio 错误地解析项目的引用并因此再次构建它时,无论是否有更改:

项目“XXX”不是最新的。 CopyLocal 参考源 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.ValueTuple.dll' 比 'C: \Src\Current.Release\Bin\Debug\System.ValueTuple.dll'。

为什么 Visual Studio 不采用我定义的引用或者只是失败,如果它不存在?它还在引用属性窗口中显示错误的路径。

我可以在多台机器上重现这种行为。如果我签出一个有问题的项目文件,添加一个空行并重新加载它,然后它会正确解析引用。但我的意思是,我并没有真正做出改变。如果我重新映射工作区,问题又回来了。

希望你们能帮助我。提前致谢!

【问题讨论】:

  • 为什么将其标记为私有?它现在是框架的一部分。
  • 我们必须坚持使用 .net 4.6.1 一段时间。

标签: c# .net visual-studio msbuild visual-studio-2017


【解决方案1】:

Visual Studio 2017 无法正确解析特定引用

因为:

这是由于对 NETStandard 2.0 的注入支持。我们将新程序集注入到 NET 4.6.1 及更高版本的桌面项目中,以便 添加对 netstandard2.0 的支持。我们现在在目标中执行此操作,而不是 包,因为它不再需要引用包 建立一个网络标准库。每当我们看到一个 引用了 netstandard1.5 或更高版本的库(参见 dotnet/sdk#1386)。

要解决此问题,您可以将绑定重定向添加到这些引用。

查看System.Net.Http v4.2.0.0 being copied/loaded from MSBuild tooling了解更多详情。

希望这会有所帮助。

【讨论】:

  • 但是绑定重定向只在运行时被考虑,对吧?所以这些并不能帮助我摆脱这样一个事实,即我的项目正在一遍又一遍地构建,因为版本差异?!为什么微软不简单地将相同版本的程序集放在他们正在我的机器上安装的 nuget 上?
【解决方案2】:

我感觉到你的痛苦。 System.Net.Http 有类似的问题。我要说的很多内容都是轶事,在我脑海中是半生不熟的。据我了解,MS 开始放弃单独的系统 nupkg,转而使用框架提供 DLL:

We're dead-ending all those packages with the intent that they become part of the framework again in .net 4.7.1. The goal of netstandard2 is to stop the whole package-based portability model because of all of these problems.

我认为 VS 2017 有特殊情况逻辑:

I don't understand what you mean. When you use the latest NuGet package, it contains information INSIDE the package to use the FRAMEWORK DLL instead when you target .NET Framework 4.5+. That is entirely intentional behavior / setting of the NuGet package.(参见 Karel 在 04:45 的评论)

another comment detailing similar observations as yours

顺便说一句,鉴于你是 VS2017,你会考虑使用 &lt;PackageReference 元素而不是 packages.config 文件吗?

【讨论】:

  • 因此,如果我有一个项目引用了一个面向 .NET Standard 2.0 的程序集,Visual Studio 将使用较新版本的依赖程序集(如 System.ValueTupleSystem.Collections.Immutable 等.),哪些(尚未)在 nuget 上可用?
  • 我承认我真的不知道,只是 MS 似乎对这方面的行为有一些难以解释的原因——尤其是在从 4.6.1 -> 4.7 转换的过程中,我还没有找到一个确定的参考。此外,还有很多关于 BindingRedirects 的东西会增加噪音水平,因为(ASAIK)它们只在运行时启动,而不是在编译时启动。最后,我认为他们搞砸了一些版本编号 - nuget 包版本不匹配 AssemblyVersions 不匹配 FileVersion,这也增加了混乱和反直觉 BindingRedirects
  • 我认为你是对的,他们可能搞砸了一些版本编号。也许我错过了一些东西,但如果微软会在 nuget 上提供完全相同版本的程序集,它们正在本地安装在计算机上,那么所有问题不会消失吗?
【解决方案3】:

如果您遇到此问题,我建议您检查两个项目是否使用相同的 .Net Framework 版本。

我解决了将 DAL 项目的 .Net Framework 从 4.5.2 降级到 4.5 时遇到的相同问题。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-10-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多