Создание двух приложений C ++, использующих одну и ту же DLL в версии 2010 - PullRequest
3 голосов
/ 09 июня 2011

У меня есть приложения A и B, оба используют dll D.
A, B и D являются проектами C ++ в версии 2010 года.

A.sln и B.sln - файлы решений, которые создают приложенияA и B.
И в A, и в B есть ссылка на dll D.

Ожидаемые места для приложений и dll (при условии отладочных сборок):
A / Debug / A.exe
A / Debug / D.dll
B / Debug / B.exe
B / Debug / D.dll

Приходит странная часть: когда я перестраиваю (или дажечистый) решение B, он как-то
удалил A / Debug / D.dll, хотя эти два приложения никак не связаны.

Есть ли способ указать, чтобы при восстановлении B удалялся только файл D.dll из-под B?

Ответы [ 3 ]

2 голосов
/ 17 июня 2011

Каков путь подсказки для решения B со ссылкой на D?

Если путь подсказки указывает на Решение А, это ваша проблема.Удалите ссылку, скопируйте файл D.dll, где бы он ни находился, в папку вашего решения B, а затем перестройте ссылку, используя этот путь, а не путь решения А.

1 голос
/ 19 июня 2011

А как насчет решения А? Что происходит, когда вы восстанавливаете его? Удаляет ли это DLL?

Если нет, проверьте:

  1. Проект D является частью решения A (или нет).
  2. Зависимости проекта от D, A.
  3. «Ссылки» и соответствующие настройки компоновщика.

В случае несоответствия решениям A, B; вам нужно применить то же самое в решении А.

1 голос
/ 09 июня 2011

Вы создали проект, скопировав *.vcproj и переименовав несколько вещей? Если это так, то вы, вероятно, столкнулись с GUID, использованным для идентификации проекта. (Это не редкая проблема во многих магазинах разработки.)

Microsoft использует GUID, который кэшируется в реестре Windows для каждого проекта, созданного на этой машине, чтобы «найти» упомянутый проект и найти его на жестком диске. (Таким образом, *.sln файлы не будут «ломаться», когда проекты, на которые они ссылаются, перемещаются на жесткий диск; аналогично, проекты могут ссылаться на другие проекты таким образом, а не «ломаться», когда вы перемещаете вещи.)

Напомним, что каждый проект имеет GUID, который является глобально / универсально уникальным для идентификации проекта (если у вас есть коллизия, это будет так), и другой GUID, который идентифицирует «тип проекта» (например, DLL, EXE , Сборка .NET и т. Д.) Существуют дополнительные идентификаторы GUID для определения «наборов файлов» в проекте, но я еще не выяснил, как они используются (пока).

Microsoft перечисляет некоторые GUID типа проекта по адресу: http://msdn.microsoft.com/en-us/library/hb23x61k%28v=vs.80%29.aspx

... и вы можете получить более полный список тридцати или около того, выполнив поиск в Интернете, например:

http://onlinecoder.blogspot.com/2009/09/visual-studio-projects-project-type.html

Идентификаторы GUID "уникальный для проекта" просто генерируются любым генератором GUID, поэтому ожидается, что они будут действительно уникальными.

...