Visual Studio 2008 управляемая инкрементная сборка не работает

Question

В моем управляемом проекте C ++ включен «Managed Incremental Build». У меня есть DLL, написанная на C #, и решение содержит проекты C ++ и C #. Я не определил никаких зависимостей между проектами, но на C # DLL ссылается проект C ++.

Проблема в том, что всякий раз, когда проект C # перестраивается, проекты C ++ полностью перестраиваются. Я получаю это сообщение об ошибке, когда это происходит:

Не удается проверить c: \ MyProj \ MyCScode.dll. Предполагая значительные изменения.

Я использую Windows 7 на виртуальной машине (это может быть проблема с синхронизацией?).

Answer 1

Я думаю, что нашел обходной путь:

Я явно добавил $ (OutDir) в «Resolve #using References» в «C / C ++ | Общая «опция» каждого проекта C ++ / CLI. После этого «Невозможно проверить ... Предполагая значительные изменения». сообщение больше не появлялось в случае внутренних изменений сборки, и управляемая инкрементная сборка работала как ожидалось.

Answer 2

После некоторого исследования мой коллега сказал мне, что это подтвержденная ошибка в Visual Studio 2008 SP1, что нет доступных исправлений, и что удаление SP1 решает проблему. У меня нет ссылки на эту информацию.

Наше решение состояло в том, чтобы переместить файлы реализации C # из проекта C ++ и сделать так, чтобы они компилировались с использованием пользовательского шага сборки (с помощью параметра / target: module для csc.exe), и включить объектные файлы в исходный код C ++ файлы, которые ссылаются на наши управляемые типы C #, например:

#using "MyCScode.obj"

Предостережения:

Сетевой модуль должен использовать расширение .obj, это похоже на ошибку в том, как Visual Studio определяет, какие входные данные будут использоваться для компоновщика (обычно вместо этого вы называете его .netmodule).

Мы по-прежнему получаем полную перестройку всех исходных файлов C ++, имеющих #using, при каждом обновлении файлов C #. Но это лучше, чем полная перестройка всего проекта.