MSBuild 不获取被引用项目的引用答案

【问题标题】：MSBuild doesn't pick up references of the referenced projectMSBuild 不获取被引用项目的引用
【发布时间】：2010-09-13 07:51:16
【问题描述】：

我刚才在使用 MSBuild 时遇到了一个奇怪的情况。有一个解决方案包含三个项目：LibX、LibY 和 Exe。 Exe 引用了 LibX。 LibX 又引用了 LibY，有一些内容文件，还引用了第三方库（安装在 GAC 和本地 lib 文件夹中的几个预构建程序集）。第三方库被标记为“复制本地”（“私有”）并出现在 LibX 项目的输出中，就像 LibY 的输出和 LibX 的内容文件一样。现在，Exe 项目的输出有 LibX 项目输出、LibX 项目的内容文件、LibY 项目输出（来自 LibX），但没有第三方库的程序集。

现在我通过直接在 Exe 项目中引用第三方库来解决这个问题，但我觉得这不是一个“正确”的解决方案。

以前有人遇到过这个问题吗？

【问题讨论】：

任何带有完整源代码示例的最终解决方案？

标签： msbuild build-automation dependencies

【解决方案1】：

与使用 Visual Studio 构建相比，使用 MSBuild（即命令行、TFS Build 和其他工具）构建时的行为有所不同。辅助引用不包含在发送到 MSBuild 编译任务的引用变量中。

MSBuild 提供了几个扩展点来更改解析引用的方式。我已经成功地使用 AfterResolveReference 为我的一些项目解决了这个问题 - I have posted more info about the background on my blog。

解决方法是将以下代码添加到您的 vbproj 或 csproj 文件中

  <Target Name="AfterResolveReferences">
    <!-- Redefine referencepath to add dependencyies-->
    <ItemGroup>
     <ReferencePath Include="@(ReferenceDependencyPaths)">
     </ReferencePath>
    </ItemGroup> 
  </Target>

Microsoft 已声明不会在 Connect 上解决此问题

【讨论】：

优秀。这实际上是解决问题的更好方法。

【解决方案2】：

您实际上可以进入 Microsoft.CSharp.targets 或 Microsoft.VisualBasic.targets 文件（位于框架目录，通常为 C:\Windows\Microsoft.NET\Framework\v3.5）并修改 csc 或 vbc任务参数以包含其他参考依赖项。在文件中（VB 目标，第 166 行；C# 目标，第 164 行）更改：\

References="@(ReferencePath)"

到

References="@(ReferencePath);@(ReferenceDependencyPaths)"

这可能会导致其他问题，具体取决于事情的复杂程度，并且它可能会在 Visual Studio inproc 编译器中发挥作用，但这是我发现的在 MSBuild 中执行此操作的唯一方法。

【讨论】：

起初这对我没有任何影响，但后来我发现（至少在 Framework\v4.0.30319 中）该行在每个 .targets 文件中出现两次。

【解决方案3】：

josant 的回答几乎对我有用；当我尝试这样做时，我在 Visual Studio 中不断收到错误：

尝试为 IDE 的进程内编译器设置“References”参数时出现问题。对 COM 组件的调用已返回错误 HRESULT E_FAIL

我的问题的解决方案是在 ItemGroup 上设置一个条件，如下所示：

<Target Name="AfterResolveReferences">
  <!-- Redefine referencepath to add dependencies-->
  <ItemGroup Condition=" '$(BuildingInsideVisualStudio)' != 'true' ">
    <ReferencePath Include="@(ReferenceDependencyPaths)"></ReferencePath>
  </ItemGroup>
</Target>

这导致 Visual Studio 完全忽略引用更改，并且构建在本地和构建服务器上都可以正常工作。

【讨论】：

【解决方案4】：

是的，我也遇到过这个问题。虽然我很想说别的，但我相信您必须在构建文件中包含所有传递依赖项作为引用。

【讨论】：

【解决方案5】：

我已将 Alex Yakunin 的 solution 与 also copy native dll's 结合在一起。

【讨论】：

【解决方案6】：

如果您有一个有向图而不是树并出现“尝试部署不同的 dll 副本”错误，则 AfterResolveReferences 方法将失败。（参见How to configure msbuild/MSVC to deploy dependent files of dependent assemblies）

【讨论】：