Вызывает ли последнее обновление безопасности для Visual Studio 2005 проблемы с библиотекой времени выполнения C при оперативном исправлении сайтов клиентов

Question

Как вы, возможно, знаете, обновление Visual Studio 2005 было автоматически обновлено на большинстве машин на прошлой неделе. Это обновление включает новую версию библиотеки Visual C времени выполнения. В результате любые двоичные файлы, созданные после обновления, также требуют установки нового распространяемого ПО на клиентских системах.

См. http://support.microsoft.com/kb/971090/

И вот установщик для нового распространяемого:

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=766a6af7-ec73-40ff-b072-9112bab119c2

Это хорошо для распространения новых двоичных файлов среди клиентов, я отправлю новый распространяемый пакет вместе с установщиком, и все будет работать.

Однако меня очень беспокоит моя способность исправлять существующие сайты клиентов, если они обнаружат ошибку. В этом случае обычно я просто отправлял dll или exe, которые были исправлены.

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

• Это проблема?
• Может ли это вызвать сбой моего приложения?
• Что произойдет, если я выделю память в одной dll, а затем выделю ее в другой? Обычно это работает, если используется одна и та же библиотека времени выполнения выпуска. Я просмотрел наш код около 3 лет назад, чтобы очистить его, но я не уверен, что нашел и исправил все вхождения.
• Является ли проблема выделения / освобождения в разных библиотеках по-прежнему проблемой? Теперь, когда в эпоху умных указателей и т. Д. Это очень требовалось.
• Можно ли изменить манифесты в зависимости от версии библиотеки времени выполнения?

Любые указатели или советы будут благодарны.

Обновлено: Я только что заметил этот вопрос VC ++: KB971090 и выбор зависимостей DLL среды выполнения Visual C Это очень похоже, но мой вопрос больше касается использования двух разных версий среды выполнения в одном исполняемом файле.

Answer 1

Номер версии, указанный в файле / ресурсе манифеста приложения, указывает только минимальную версию, необходимую для запуска приложения. Поведение загрузчика по умолчанию - сначала проверить папку WINDOWS \ WinSxS на наличие идентичной версии или заменяющей версии зависимости, указанной в манифесте приложения, и использовать эту версию независимо от того, была ли закрыта сборка, содержащая зависимость. предоставляется с приложением. (См. http://msdn.microsoft.com/en-us/library/aa375674(VS.85).aspx).

Так что, скорее всего, ваши старые двоичные файлы все равно будут использовать последнюю версию библиотеки времени выполнения Microsoft. Попробуйте запустить сборку релиза вашего приложения (созданную до обновления Visual Studio) на полностью исправленной машине и используйте проводник процессов, чтобы увидеть, какие DLL-библиотеки загружаются. Единственная проблема заключается в том, что вам нужно будет включить новый распространяемый файл времени выполнения в ваш патч.

Если вы все еще беспокоитесь, вы можете попробовать метод, описанный здесь: http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/

Answer 2

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

Если вы выделите память во время выполнения и попытаетесь освободить ее с другим, ваше приложение потерпит крах. Это есть и будет проблемой.

Только среда выполнения, зарезервировавшая память, может отслеживать ее. Для другой среды выполнения невозможно узнать, сколько памяти вы зарезервировали.

Вы можете прочитать this , действительно хороший пост о связывании с msvcrt.dll.

Answer 3

Я слышал (только по слухам), что если манифест дает две версии CRT, которые отличаются только младшим номером ревизии, то приложение заканчивается только использованием более новой версии во время выполнения. Т.е. у вас не возникает проблем с несколькими ЭЛТ.

Это всего лишь слухи, и я бы хотел услышать конкретный ответ по этому поводу.

См. Также: Обновления безопасности Visual Studio 2005 и версии DLL CRT в манифесте