MSBuild не берет ссылки на указанный проект - PullRequest
14 голосов
/ 26 сентября 2008

Я столкнулся со странной ситуацией с MSBuild только сейчас. Есть решение, которое имеет три проекта: LibX, LibY и Exe. Exe ссылки LibX. LibX в свою очередь ссылается на LibY, имеет некоторые файлы содержимого, а также ссылки на стороннюю библиотеку (несколько предварительно собранных сборок, установленных как в GAC, так и в локальной папке lib). Сторонняя библиотека помечается как «Копировать локально» («private») и отображается в выходных данных проекта LibX, как это делают выходные данные LibY и файлы содержимого LibX. Теперь выходные данные проекта Exe содержат выходные данные проекта LibX, файлы содержимого проекта LibX, выходные данные проекта LibY (поступающие из LibX), но НЕТ сборок сторонней библиотеки.

Теперь я решил эту проблему, ссылаясь на стороннюю библиотеку непосредственно в проекте Exe, но я не чувствую, что это «правильное» решение.

Кто-нибудь имел эту проблему раньше?

Ответы [ 6 ]

12 голосов
/ 17 февраля 2012

Существует разница в поведении при сборке с помощью MSBuild (то есть командной строки, TFS Build и других инструментов) по сравнению со сборкой с помощью Visual Studio. Вторичные ссылки не включены в переменную ссылок, отправляемую в задачи компиляции MSBuild.

Существует несколько точек расширения, предоставляемых MSBuild для изменения порядка разрешения ссылок. Я успешно использовал AfterResolveReference, чтобы исправить эту проблему для некоторых из моих проектов - Я разместил больше информации о фоне в моем блоге .

Обходной путь - добавить следующий код в файлы vbproj или csproj

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

Microsoft заявила, что это не исправит Connect

4 голосов
/ 03 октября 2008

На самом деле вы можете перейти в файл Microsoft.CSharp.targets или Microsoft.VisualBasic.targets (расположенный в каталоге framework, обычно C: \ Windows \ Microsoft.NET \ Framework \ v3.5) и изменить csc или vbc параметры задачи для включения дополнительных ссылочных зависимостей. В файле (цели VB, строка 166; цели C #, строка 164) измените: \

References="@(ReferencePath)"

до

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

Это может вызвать другие проблемы, в зависимости от того, насколько сложны вещи, и может подшучивать с помощью inproc компилятора Visual Studio, но это единственный найденный способ сделать это в MSBuild.

3 голосов
/ 02 февраля 2013

ответ Иосанта почти сработал для меня; Я продолжал получать сообщение об ошибке в Visual Studio, когда я пытался это:

Возникла проблема при попытке установить параметр «Ссылки» для внутрипроцессного компилятора среды IDE. Ошибка HRESULT E_FAIL была возвращена после вызова COM-компонента

Решением моей проблемы было наложение условия на ItemGroup, например:

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

Это привело к тому, что Visual Studio полностью проигнорировал изменение ссылки, и сборка отлично работает локально и на сервере сборки.

3 голосов
/ 26 сентября 2008

Да, у меня тоже была эта проблема. Хотя я хотел бы сказать иначе, я считаю, что вы должны включить все переходные зависимости в качестве ссылок в свой файл сборки.

2 голосов
/ 02 мая 2011

Я объединил решение Алекса Якунина с решением, которое также скопирует .

нативной библиотеки DLL.
0 голосов
/ 16 марта 2012

Метод AfterResolveReferences завершается ошибкой, если у вас есть ориентированный граф, а не дерево с ошибкой «попытка развернуть разные копии dll». (см. Как настроить msbuild / MSVC для развертывания зависимых файлов зависимых сборок )

...