19

我想知道如何确定此构建错误的来源；

Warning 4   The primary reference "MyNamespace.MyProject" could not be resolved because 
   it has an indirect dependency on the .NET Framework assembly "System.Xml, Version=4.0.0.0,
   Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "4.0.0.0" than
   the version "2.0.0.0" in the current target framework.   MyNamespace.MyOtherProject

我理解这个错误的含义（以及同一个项目中其他 5 个喜欢它的错误），但我无法解决在我的情况下如何解决它。在这种情况下，“主要参考”（MyNamespace.MyProject）对 .NET 4.0.x 没有直接依赖关系。

主要参考仅依赖于我的另一个项目 (MyNamespace.MyCoreProject)，构建的源项目 (MyNamespace.MyOtherProject) 也直接依赖于该项目。并且构建并没有抱怨该项目间接引用了 .NET 4.0.x，所以我认为我可以排除这种情况。

主要参考直接依赖于三 (3) 个第 3 方 DLL，所有这些 DLL 也都以 .NET 2.0 为目标。

我使用 dotPeek 来检查构建的库，并且看不到对使用 .NET 4.0 的任何内容的任何引用。

作品中唯一的其他潜在扳手是 PostSharp 的使用，它由“MyNamespace.MyCoreProject”直接引用（由主要参考项目引用），这可能会导致问题，因为我相信有一个相关的 VS2010 错误时引用 PostSharp.dll (http://www.sharpcrafters.com/forum/Topic4444-4-1.aspx#bm4462)，但是我也从构建链中删除了它，仍然看到这个错误，所以我假设我也可以统治那出来。

如果有人能告诉我为什么会这样，太棒了！如果没有，关于如何找出未命名的“间接引用”的一些指导将同样有帮助！

顺便说一句，我已经尝试了以下所有工具来获取一些信息，但它们并没有告诉我很多我不知道的东西（这是有问题的 DLL 的直接依赖项）；- .NET 反射器 - dotPeek - IldAsm - Depends (Dependency Walker)

4

8 回答 8

7

虽然我实际上还没有找到一个好方法来实际解决确定 MsBuild 如何确定它使用的引用的问题（为什么它不只是告诉我它是如何产生这些间接引用的，而不是让我猜我没有知道...）我已经解决了我的问题。

最后，我基本上删除了“主要引用”项目中的所有引用（这需要逐段排除所有代码 - 一个有点痛苦的过程）以确定假定的对 .NET 4.0 库的间接引用的来源是由引用的第 3 方 DLL。

但是，我确实相信这个问题背后的 MsBuild 中有一个错误，因为；

  1. 第 3 方 DLL 被“浏览”引用到我机器上的特定 DLL 文件 - 一个非常明确地仅依赖于 .NET 2.0
  2. 在构建中将“特定版本”设置为 true 并没有解决此问题
  3. MsBuild 似乎要向 GAC 寻求此 DLL 的不同版本，并导致不正确的引用错误。

现在，另一个好奇心是我已经有一段时间没有接触或更改相关的库了，所以这只是由于其他一些不相关的原因才开始发生 - 这可能是什么，我不知道。

最后，我发现解决此问题的唯一方法是为每个相关库运行gacutil /u以删除以前安装/使用的 4.0 库版本。（包中大约有 40 个，所以这也很痛苦！因为包的卸载程序没有删除 GAC 中的库）

这似乎让 msbuild 开始使用我告诉它的引用，而不是想出自己的想法“使用这个文件”和“使用这个特定版本的含义”。

解决了，但我会喜欢一种更清洁的方法来做到这一点！

于 2012-06-07T00:26:03.293 回答
2

尝试对所有可疑程序集使用MSIL Disassembler工具。

  1. 打开 Dll，单击 Ctr + M 并转到屏幕末尾。您可能会看到对某些 .NET 4 程序集的引用，如下所示：

AssemblyRef #1 (23000001)

Token: 0x23000001
Public Key or Token: b7 7a 5c 56 19 34 e0 89 
Name: mscorlib
Version: 4.0.0.0
Major Version: 0x00000004
Minor Version: 0x00000000
Build Number: 0x00000000
Revision Number: 0x00000000
Locale: <null>
HashValue Blob:
Flags: [none] (00000000)

  1. 使用inf ref # 查找从该.NET 程序集加载的类型作为搜索条件。这是您可以在屏幕中找到的类型示例

    TypeRef #18 (01000012)

    令牌：
    0x01000012 ResolutionScope：0x23000001
    TypeRefName：System.Runtime.CompilerServices.CompilationRelaxationsAttribute

  2. 调查为什么使用该类型。

更新： 您是否尝试在 Tools\Options\Projects and Solutions\Build And Run 页面上将 MSBuild Project Build Output Verbosity 设置为“Detailed”，然后重新构建解决方案？你可能会在 ResolveAssemblyReference 目标中看到一些东西

于 2012-06-06T03:55:40.227 回答
2

我遇到了这个问题，并使用 CheckAsm 确定我自己的一个程序集出于某种奇怪的原因引用了 3rd 方库的 .NET 4.0 版本，而应用程序本身是 .NET 2.0。我从我的硬盘驱动器中删除了该程序集的所有实例（周围有很多副本），重建了解决方案，一切都很好。

于 2013-12-06T01:17:39.093 回答
2

就我而言，程序集已卸载，并且所有引用（据我所知）都已删除。

在 app.config 中找到它：

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            ...
        </dependentAssembly>
    </assemblyBinding>
</runtime>

删除了dependentAssembly 并让我的应用程序再次运行。

于 2016-12-20T05:48:25.890 回答
1

我也遇到了这个问题，event.er 引导我找到解决方案。我的 app.config 中有以下内容：

  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="4.0.0.0" />
  </dependentAssembly>

我将 newVersion 更改为“2.0.0.0”并构建了解决方案。

于 2017-02-08T09:04:20.733 回答
0

我的猜测是第 3 方 DLL 是一个没有将特定版本设置为 true 的依赖项并导致您的问题。

于 2013-09-24T01:06:07.770 回答
0

我在一个针对 .NET 4.5 的项目中遇到了System.Data.SQLite.dll的问题，结果是针对 4.5.1 的版本已安装到 GAC_32。

如果我用 构建解决方案Copy Local = True，一切都会好起来的。但是当我在最终构建中嵌入 SQLite 程序集时，这似乎是不必要的，我想对其进行整理。

我尝试运行gacutil -u System.Data.SQLite.dll但遇到了问题，所以最后我只是使用 Windows 的程序和功能来卸载它，然后一切都很好。

于 2018-09-07T18:20:22.103 回答
0

如果使用 Visual Studio 2019 并尝试构建 .NET 3.5 项目，这将有所帮助。

Visual Studio 服务包和较新的 Visual Studio 2019 将一个程序（通常是 WebDeploy）放在 Program Files 中，并将此文件夹放在您机器的程序集探测路径的高位（因此 net45 JSON.NET 程序集在任何其他程序集之前被拾取）。

要弄清楚您的问题是从哪里解决的，只需使用 SysInternals Process Monitor 并过滤引用的 DLL。然后开始你的构建。Process Monitor 会告诉你它从哪里解析该程序集，它通常是 VS2019 安装的 WebDeploy 文件夹中的那个。如果您不使用 WebDeploy 工具，您可以清除该文件夹。

具体来说，就我而言，我删除C:\Program Files\IIS\Microsoft Web Deploy V3\Newtonsoft.Json.dll并且我的构建工作。

于 2020-09-02T00:41:56.283 回答