Есть ли побочные эффекты от использования макроса _BIND_TO_CURRENT_VCLIBS_VERSION? - PullRequest
13 голосов
/ 24 июля 2011

Мы переносим проект VC ++ из Visual Studio 2003 в Visual Studio 2008 SP1 (9.0.30729.4148). Зависимые внешние библиотеки также скомпилировано с Visual Studio 2008 SP1.

MainApp - Main application Compiled with VS SP1 9.0.30729.4148
ExtStaticLib1 - External static library compiled with VS  SP1 9.0.30729.4148
ExtDynamicDll1 - External DLL compiled with VS  SP1 9.0.30729.4148

Для основного приложения есть два сценария развертывания:

  • Машина с правами администратора пользователя: Мы рекомендуем поставить обязательное условие для установки распространяемого пакета Visual Studio перед использованием приложения MainApp. Это хорошо работает, так как у пользователя есть права администратора, и установка распространяемого пакета не имеет проблем. Приложение автоматически связывается с библиотеками перенаправления VC в папках WinSxS.
  • Машина с пользователем без прав администратора: Этот сценарий проблематичен. Пользователь не имеет прав администратора. Следовательно, невозможно установить распространяемый пакет VS2008SP1.

Мы делаем следующее, чтобы решить эту проблему:

  • Скомпилируйте цели MainApp с помощью макроса _BIND_TO_CURRENT_OPENMP_VERSION (для всех проектов в MainApp).

  • Распространите распространяемые библиотеки VS2008SP1 как частные сборки и скопируйте их в каталог установки приложения.

Вопросы:

  1. Есть ли какой-либо побочный эффект от использования флага _BIND_TO_CURRENT_VCLIBS_VERSION (особенно, когда совместно распространяемый пакет VC и частные сборки перенаправления VC существуют вместе)?
  2. У нас нет большого контроля над внешними библиотеками ExtStaticLib1, ExtDynamicDll1 и, следовательно, они не будут компилироваться с помощью макроса _BIND_TO_CURRENT_OPENMP_VERSION. Но они уже скомпилированы с VSSp1. Будут ли какие-либо проблемы с этой настройкой?
  3. Возникнут ли какие-либо проблемы, если будет доступна более новая версия распространяемого VS (более новая, чем 9.0.30729.4248).

Спасибо.

Ответы [ 2 ]

2 голосов
/ 28 июля 2011

Я бы не использовал ни одного макроса BIND. Проблемы начнутся раньше, чем позже.

Даже если вы распространяете библиотеки времени выполнения VC как частные сборки, вы не можете быть уверены, что у пользователя их еще не установили с каким-либо другим приложением.

Одна проблема, которая возникает, заключается в том, что вы можете получить манифест, который ссылается на несколько версий c-runtime. Здесь это открытый вопрос по этому поводу (к вашему сведению: у меня была та же проблема!).

Так что, если нет причины, которая заставляла бы вас использовать только очень специфическую версию среды выполнения c, а не последнюю совместимую, не используйте эти определяющие макросы!

1 голос
/ 28 июля 2011

Нашел этот блог ресурс, на котором есть ответ на ваш вопрос.Обратитесь к разделу «Обновления, исправления и пакеты обновления» http://helgeklein.com/blog/2010/03/deploying-visual-c-runtime-files-as-private-assemblies/

...