MSBuild не может собрать сборки друзей C ++ / CLI - PullRequest
Новая
       12

MSBuild не может собрать сборки друзей C ++ / CLI

0 голосов
/ 10 февраля 2009

У меня Visual Studio 2008 SP1, два проекта C ++ / CLI, скажем, proj1 и proj2. proj2 зависит от proj1, но странным образом (см. ниже). В Project Dependencies я указываю, что proj2 зависит от proj1. Также ссылки на proj2 включают proj1. Тогда я хочу, чтобы proj1 был другом proj2, Итак, как написано на странице MSDN «Сборки друзей» , я пишу где-нибудь в proj2 этот код: 

#using "proj1.dll" as_friend.

Компиляция говорит, что proj1.dll уже упоминался, и что я должен удалить ссылку на проект из настроек проекта proj2 (таким образом удаляя флаг / FU).

Вот ошибка (?): Если я удалю ссылку на proj1 из proj2, но все же укажу в решении Project Dependencies, что proj2 зависит от proj1, все компилируется нормально в VS2008. Но MSBUILD анализирует ссылки на проекты, создает новый временный проект для proj2, ADDS /FU:proj1.dll и СОСТАВИТЬ ОТКАЗЫ!

Вопрос 1: есть ли способ отключить это поведение MSBuild?

Затем, если я удаляю зависимости в Project Dependencies, MSBuild строит нормально, но Visual Studio пытается скомпилировать proj1 и proj2 параллельно и завершается неудачно, потому что proj2 намного меньше и компилируется первым ... Настройка параметра max параллельных сборок в Project и Solutions / Build and Run помогает, но я должен сделать это на каждой машине разработчика, я не могу сохранить этот параметр в решении, это замедляет сборку и т. д ...

Вопрос 2: есть ли способ сделать «Зависимости проекта» условным вариантом? Я хочу включить VS2008 и MSBuild ...

Ответы [ 2 ]

2 голосов
/ 25 января 2010

Как ОП уже выяснил, это на самом деле ошибка. ошибка была подана ФП и признана Microsoft. Похоже, что это влияет на VS2005, VS2008 и VS2010 (нацелены на VS2008).

Обходной путь, который я использовал, был фиктивным промежуточным проектом для «буферизации» ссылок между двумя зависимыми проектами.

0 голосов
/ 21 апреля 2009

Если ProjA зависит от ProjB, а ProjB зависит от ProjA, то я удивлен, что вы можете построить его вообще! Этот тип циклической сборки обычно убивает чистые сборки. Вы часто избегаете этого на машинах разработчиков, где старый ProjA все еще лежит, когда вы создаете ProjB и vise-vera. Но на чистой машине (сервере сборки) такая зависимость часто ломает вещи.

В зависимости от того, что это за зависимости, может быть проще всего перенести общие зависимости в новую сборку ProjC, которая не имеет собственных зависимостей, но от которых зависят как ProjA, так и ProjB. Это означает, что затем вы можете собрать ProjC, затем ProjA и ProjB в любом порядке. Этот вид рефакторинга часто наиболее прост, когда вы зависите только от интерфейсов от ProjC, а не от конкретных классов.

Не уверен, что это полностью отвечает на ваш вопрос, но может предложить альтернативный способ его устранения.

Colin

...