MSBuild не может построить дружественные сборки C ++ / CLI

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

#using "proj1.dll" as_friend.

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

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

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

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

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


msbuild c++-cli friend
person Community    schedule 10.02.2009    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

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

person Community    schedule 25.01.2010

arrow_upward
0
arrow_downward

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

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

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

Колин

person Community    schedule 21.04.2009