статически и динамически связывать библиотеки DLL, созданные в разных версиях Visual Studio - PullRequest
Новая
       33

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

3 голосов
/ 15 июня 2009

вот ситуация, которую я ищу для обратной связи:

  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, и того, имеет ли это значение, если различные слои связаны статически или динамически.

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

1 Ответ

2 голосов
/ 15 июня 2009

Если сигнатуры функций, экспортируемых из 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 и любых типов параметров функций.
...