статическое и динамическое связывание библиотек DLL, созданных с помощью разных версий Visual Studio.

вот ситуация, о которой я ищу отзывы:

  1. На работе одной из моих обязанностей является поддержка нескольких устаревших приложений, одно из которых мы назовем «LegacyApp». Он всегда компилировался с VS 6.0. (И в наши дни его мало трогают.)
  2. Он использует API, который обеспечивает доступ к некоторому специализированному оборудованию. Этот API создан другой группой в моей компании. Мы назовем этот API «ControllerAPI». Он всегда компилировался с VS 6.0.
  3. Разработчики LegacyApp также написали DLL-оболочку вокруг ControllerAPI, которую будет использовать LegacyApp. Мы назовем это «WrapperAPI». Я несу ответственность за поддержание этого. Он всегда компилировался с VS 6.0.
  4. WrapperAPI статически связывается с ControllerAPI.
  5. LegacyApp динамически создает чернила в соответствии с WrapperAPI.
  6. В своем следующем выпуске группа, которая делает ControllerAPI, начала компилировать его с помощью VS 2008, а не VS 6.0, как это было до этого момента.

Итак, вот мои вопросы:

  1. Поскольку WrapperAPI статически связан с ControllerAPI, мне нужно будет скомпилировать WrapperApi с VS 2008? Это правильно? (Я уже сделал это, в этом случае это был простой шаг.)
  2. Поскольку LegacyApp динамически связывается с WrapperAPI, могу ли я продолжать компилировать LegacyApp в VS 6.0? Если да, то есть ли что-то, что мне нужно сделать в моей компиляции WrapperAPI, чтобы убедиться, что это все еще так. Или мне нужно будет скомпилировать устаревшее приложение в VS 2008, чего я бы не хотел делать в настоящее время.

Итак, мой вопрос сводится к запуску приложений и библиотек DLL друг с другом, которые были скомпилированы с разными версиями Visual Studio, и имеет ли значение, связаны ли различные слои статически или динамически.

Спасибо за любой отзыв


linker visual-studio-2008
person Community    schedule 15.06.2009    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Если сигнатуры функций, экспортированных из ControllerAPI и WrapperAPI, не изменились, ваши привязки должны быть в порядке, статические или динамические.

Однако, если типы и объекты, используемые функциями (входные, выходные, возвращаемые параметры), зависят от внешней библиотеки; то у вас могут быть проблемы.

Например, скажем, если ControllerAPI выделяет память для одной версии среды выполнения C, а WrapperAPI ожидает, что сможет освободить ее самостоятельно, то в этом случае они оба должны быть связаны с одной и той же версией среды выполнения C. Если вы воссоздали проект в VS2008 вместо его импорта и обновления, то ваши цели компиляции по умолчанию и импортированные библиотеки могли измениться. Подобные проблемы можно наблюдать в библиотеках, созданных с типами, известными MFC, ATL и т. д.

К сожалению, вам нужно будет проверить эти сценарии вручную, но если вы можете отметить следующие пункты, все будет в порядке. Я также должен отметить, что эти вещи также будут проверяться между любыми двумя заданными версиями Visual Studio и даже любыми двумя сборками в отношении разных целей компиляции или версий Platform SDK.

  1. Нет случаев, когда какой-либо DLL необходимо знать о ссылках, связанных с другой DLL (память/дескриптор/выделение ресурсов). Однако это нормально, если WrapperAPI учитывает элементы из ControllerAPI и обрабатывает их надлежащим образом (например, ControllerAPI выделяет что-то, WrapperAPI использует это, а затем передает обратно ControllerAPI для выпуска/уничтожения).
  2. Нет различий в выравнивании памяти в структурах, используемых обеими библиотеками DLL.
  3. Никаких изменений в типах параметров, которые определены. Остерегайтесь случаев, когда одна версия объявляет переменную 32-битного типа, но при перекомпиляции в VS2008 может быть 64-битной для некоторых целей компиляции (LONG).
  4. Никаких изменений в соглашении о вызовах (cdecl/pascal/и т.д.) для экспортируемых/импортируемых функций DLL и любых типов параметров функций.
person meklarian    schedule 15.06.2009