Я пишу простое приложение C++ в Visual Studio. Он также имеет проект установки. Оно хорошо работает на моем компьютере для разработки, но когда я устанавливаю это приложение на компьютере пользователя, для него требуется Visual C++ Redistributable Package. Мне интересно, почему моему приложению требуется C++ Redistributable? Стандартная C++ библиотека времени выполнения поставляется вместе с Windows, не так ли?
Почему для моего приложения требуется распространяемый пакет Visual C++?
Ответы (2)
Единственная версия библиотеки времени выполнения C, которая поставляется Microsoft с большинством 32-разрядных версий Windows, — msvcrt.dll. Эта библиотека предоставляет стандартный набор библиотечных функций, необходимых для программ на C и C++. К ним относятся манипуляции со строками, выделение памяти, вызовы ввода-вывода в стиле C и т. д.
Компилятор Visual Studio 6.0 связывается с этой библиотекой, поэтому, если вы разрабатываете в VS 6.0, у вас не должно возникнуть никаких проблем на компьютерах большинства пользователей.
Однако, если вы разрабатываете в VS 2005, VS 2008, VS 2010, VS 2012, VS 2013 или VS 2015, вам необходимо распространять дополнительные библиотеки времени выполнения C вместе с вашим приложением. Это связано с тем, что их компиляторы ссылаются на msvcrt80.dll, msvcrt90.dll, msvcrt100.dll, msvcrt110.dll, msvcrt120.dll и msvcrt140.dll соответственно, которые не поставляются с Windows.
Решения:
- #P4# #P5# <блочная цитата> #P6#
Другое возможное решение — потребовать, чтобы на компьютере пользователя был установлен соответствующий распространяемый пакет Microsoft Visual C++.
Это можно сделать, указав это требование в свойстве предварительных условий в вашем проекте установки.
Кроме того, вы можете распространять среду выполнения
dll, включив в проект установки соответствующий "модуль слияния". В этом случае не забудьте добавить соответствующий «модуль слияния политик», чтобы избежать ошибок, вызванных неправильной версией среды выполнения.Наконец, вы можете просто поместить необходимые библиотеки DLL в ту же папку, в которой установлено ваше приложение.
Дальнейшее чтение:
- «Распространение файлов Visual C++" — официальная документация MSDN
person
JeB
schedule
23.04.2013
Я сделаю решение 1, которое статически связано с библиотекой времени выполнения. Как я могу сделать это в VS 2013?
- person Mehmet Fide; 13.11.2014
Это очень хорошо объясняется на официальном сайте Microsoft. В двух словах, вы должны перейти в свойства проекта -> C/C++ -> Генерация кода -> Библиотека времени выполнения и выбрать опцию MT для выпуска или опцию MTd для отладки. Но имейте в виду, что, как указано в ответе выше, использование статической привязки не рекомендуется.
- person JeB; 13.11.2014
Можете ли вы уточнить, почему статическая ссылка плоха?
- person Nathan Goings; 19.01.2015
Конечно. Допустим, вы разрабатываете приложение, которое статически связывается с библиотекой времени выполнения. Это означает, что во время компоновки компоновщик будет искать функции библиотеки времени выполнения, которые вы используете, и помещать их в ваше приложение. Скажем также, что вы хотите использовать стороннюю библиотеку, которая также статически связывается с библиотекой времени выполнения. Теперь, если ваше приложение и dll, который вы хотите использовать, используют одну и ту же функцию времени выполнения (например, любую стандартную функцию), ваш компоновщик не сможет решить, какую функцию следует выбрать — из вашей библиотеки времени выполнения или из dll библиотека времени выполнения.
- person JeB; 19.01.2015
Чтобы уточнить: это проблема только времени компиляции. Когда ваша цель ссылается без ошибок на статические библиотеки импорта DLL, поскольку они используют одни и те же RTL, продукт должен работать на любой машине. Статическое связывание может быть проще и безопаснее, чем полагаться на библиотеки DLL. За более чем 25 лет разработки Windows я по возможности избегал DLL. Никогда не был другом. В настоящее время это также вопрос безопасности. Компрометация некоторых файлов msvcrtxx.dll может повлиять на многие приложения.
- person Andreas Spindler; 09.06.2015
@NathanGoings - Редкий пограничный случай: вы связываете статически и dll ссылки статически, и все в порядке. ТОГДА dll обновляется в поле, и теперь она статически связывается с другой версией общей библиотеки, которая реализует некоторую структуру иначе, чем в старой версии. Ваше приложение не может узнать, что dll использует несовместимую версию статической библиотеки. Так что дело не в том, что статическая компоновка плоха, а в том, что
mixing статическая компоновка с динамической компоновкой сопряжена с рисками, о которых вам нужно знать. Вариант № 4 (параллельное развертывание) или вариант № 3 (интеллектуальная установка) являются наиболее безопасными.
- person Jesse Chisholm; 24.08.2015
Несмотря на то, что в некоторых комментариях говорилось, что «связывайтесь статически с библиотекой времени выполнения, но это может вызвать много проблем, если в вашем приложении есть и .exe, и .dll». это неправда. Во-первых, мы НЕ связываем библиотеки DLL статически! Мы статически связываем OBJ и LIB. LIB — это статические библиотеки; DLL — это динамические библиотеки, и вы можете использовать LIB (статические) или DLL (динамические). Это полностью зависит от вас, чтобы выбрать. ЕДИНСТВЕННЫЙ недостаток (для фанатов DLL) заключается в том, что если вы хотите обновить одну библиотеку, вам нужно снова скомпилировать и скомпоновать. Я лично развертываю ВСЕ свое программное обеспечение со статическими ссылками, и благодаря этому я получаю бонус в виде того, что мне даже не нужны установщики. Программное обеспечение, которое я разрабатываю, является на 100% переносимым (функция, которая в эпоху предустановки была обычной процедурой), и конечный пользователь может просто КОПИРОВАТЬ из одной папки в другую или даже с жесткого диска на флэш-накопитель (или наоборот). наоборот). Сообщение об ошибке «DLL не найдена». просто не существует... НИКОГДА.
Некоторые считают статические компоновки игрушечным программным обеспечением: НЕПРАВИЛЬНО! Я могу написать полнофункциональное приложение, которое подключается к СУБД (Oracle, SQL Server, ...) или любому другому приложению.
person
user4377425
schedule
19.12.2014
uTorrent.exe и BitTorrent.exe, например, статически связывают среду выполнения C. Это одна из причин, по которой единственный .exe может служить в качестве собственного установщика.
- person Steve; 20.06.2015
Единственная проблема при смешивании .exe, .dll и статически связанных библиотек возникает, когда .dll является сторонней и находится вне вашего контроля. он может быть обновлен в поле для использования несовместимой версии (ранее распространенной версии) статической библиотеки. Это все еще не гарантирует, что вызовет проблемы. Но если структуры данных из одной версии статической библиотеки передаются другой версии статической библиотеки и в эти две версии внесены существенные изменения (например, управление памятью), то это МОГУТ вызвать проблемы. Итак, да, статическая ссылка на все — это хороший способ, но это увеличивает размер .exe.
- person Jesse Chisholm; 24.08.2015
чтобы продолжить - динамическое связывание и развертывание многих файлов .dll с вашим .exe означает, что вы можете выполнить обновление для исправления ошибки, обновив только одну измененную DLL. Нет необходимости повторно связывать .exe или другие файлы .dll, если вы не вносите критические изменения в обновляемую .dll. Это означает просто поддерживать
interface stability, когда вы вносите изменения в свои динамические библиотеки. @binyan отметил, что при использовании сторонних .dll у вас нет контроля, статическая ссылка на общую библиотеку может вызвать проблемы в будущем. Ваше приложение сломано из-за изменения dll вне вашего контроля.
- person Jesse Chisholm; 24.08.2015
Чтобы уточнить здесь. Я полностью согласен с автором этого ответа в том, что мы не связываем DLL статически, что означает (по иронии судьбы) Dynamic-Link Library. Я не предлагаю полностью избегать использования статических библиотек. Я говорю, что статическая связь с библиотекой времени выполнения может привести к проблемам. Если вы разрабатываете простое приложение без использования каких-либо библиотек DLL, вы можете жить со статически связанной средой выполнения. Однако, если вы используете сторонние библиотеки DLL или разрабатываете DLL самостоятельно, вам, вероятно, следует рассмотреть возможность использования динамически связанной среды выполнения (по причинам, которые я указал в своем ответе).
- person JeB; 15.08.2016
