Зависимости времени выполнения Visual Studio 2015 или как избавиться от Universal CRT?

Я смог решить эту проблему, установив параметр компилятора C/C++ > Code Generation > Runtime Library

• Для отладки: с /MDd на /MTd
• Для выпуска: с /MD по /MT

Это удалило все API-MS-WIN-CRT-* и ссылки на DLL среды выполнения и привело к статической привязке всего кода CRT.

Подробная информация о новом универсальном CRT VS2015 (динамическом и статическом) находится здесь: https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx

Я тоже боролся со статическим связыванием решения с зависимостями нескольких компонентов / библиотек проекта, импортирующих функции из различных частей MSVCRT, UCRT и ядра. Надежда заключалась в том, что получившийся EXE-файл можно было просто скопировать туда, где он был нужен (это не был продукт, который оправдал бы полную установку MSI).

Почти сдавшись, я обнаружил, что лучшим решением было следовать рекомендациям, скрытым в Объявление об универсальной среде выполнения C, в частности:

Мы настоятельно не рекомендуем статическое связывание библиотек Visual C ++ из соображений производительности и удобства обслуживания.

Просто удалите все «специальные» параметры компоновщика, которые вы пробовали, вернитесь к выбору библиотеки времени выполнения / MT | / MD (Multi-Threaded CRT DLL Release | Debug), и он будет работать везде, например более новые рабочие станции Windows 10, серверы 2012 R2 и Windows 7). Просто установите / распространите MSVCRT (VC_Redist * .exe) и KB2999226 (UCRT через Центр обновления Windows) в соответствии с рекомендациями Microsoft. , потому что, как еще говорят:

Универсальный CRT - это компонент операционной системы Windows. Он входит в состав Windows 10, начиная с январской технической предварительной версии, и доступен для более старых версий операционной системы через Центр обновления Windows.

Таким образом, логически единственной дополнительной зависимостью развертывания, которую наши решения C ++ добавляют для клиента, является MSVCRT, потому что UCRT уже должен быть там на современных / хорошо обслуживаемых машинах. Конечно, это добавляет некоторую неопределенность; вы не можете просто скопировать EXE и запустить на любой машине, хорошей или плохой.

Если вы создаете достойный пакет развертывания, такой как MSI, его просто включить, если у вас есть такие инструменты, как WIX. Также следует отметить, что начиная с недавнего SDK вы можете включать 40 с лишним DLL локально, но это не соответствует принципу обновления безопасности, поэтому я бы не стал этого делать.

Это действительно единственный поддерживаемый способ сделать это, см. другой пример здесь. В этой статье также предлагается создать ссылку на «mincore_downlevel.lib», что является важным советом, имеющим решающее значение для получения этих ошибок отсутствующей библиотеки DLL «api-ms-win *». Например:

1. Версия Project SDK установлена ​​на 10, ссылка на mincore.lib = Работает только на Windows 10, но не на сервере 8.1 / 2012 R2 или Windows 7/2008 R2.
2. Версия Project SDK установлена ​​на 8.1, ссылка на mincore.lib = Работает как на сервере Windows 10, так и на сервере 8.1 / 2012 R2, но не на сервере Windows 7/2008 R2.
3. Версия Project SDK установлена ​​на 10, ссылка на mincore_downlevel.lib = Работает на всех!

В итоге:

1. Не связывать статически, оставьте время выполнения DLL C по умолчанию выбранным в настройках проекта.
2. Вам не нужны старые SDK, вы можете разрабатывать с помощью последней версии Windows 10 SDK, но вы должны установить связь с mincore_downlevel.lib, а не mincore.lib, если вы хотите поддерживать более старые версии Windows.
3. Для простоты использования добавьте это в свой targetver.h или stdafx.h, который также документирует ваш выбор (удалите вторую строку):

// Libraries
#pragma comment(lib, "mincore.lib")             // Lowest OS support is same as SDK
#pragma comment(lib, "mincore_downlevel.lib")   // Support OS older than SDK

(Обновлено 10.11.2016).

От универсального ЭЛТ можно избавиться, связав его статически, я вернусь к нему позже, но давайте посмотрим, продолжите ли вы использовать универсальный ЭЛТ как таковой.

Согласно статье https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introduction-the-universal-crt/ - приложение можно запустить с помощью универсальных распространяемых библиотек crt dll из следующей папки: C:\Program Files (x86)\Windows Kits\10\Redist\ucrt

Всего в списке 41 файл общим размером 1.8 Мб. (пример для 64-битной платформы)

Конечно, этого недостаточно, вам потребуются дополнительно vcruntime140.dll и msvcp140.dll из следующей папки: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist\x64\Microsoft.VC140.CRT

Таким образом, после этого вы отправите всего 43 дополнительных DLL помимо вашего приложения.

Также возможно статически скомпилировать библиотеку ucrt внутри вашего приложения, после чего вам не понадобятся 43 dll, но будет ли статическая ссылка после компоновки или нет - зависит от вашего приложения - сколько dll и какие api используются. Обычно после того, как ucrt связывается с двумя разными DLL, они не обязательно используют одни и те же глобальные файлы друг с другом, что может привести к ошибкам.

Вам нужно связать vcruntime.lib / msvcrt.lib, но этого недостаточно - есть дополнительные _VCRTIMP= и _ACRTIMP= определения, которые необходимо отключить от извлечения функций из ucrt.

Если вы используете premake5, вы можете настроить свой проект следующим образом:

defines { "_VCRTIMP="}
linkoptions { "/nodefaultlib:vcruntime.lib" }
links { "libvcruntime.lib" }

с последующим:

defines { "_ACRTIMP="}
linkoptions { "/nodefaultlib:msvcrt.lib" }
links { "libcmt.lib" }

Определения не задокументированы Microsoft, поэтому возможно, что они будут изменены в будущем.

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

Что касается библиотек boost - мне тоже удалось скомпилировать boost, используя b2.exe boostrapper

boost>call b2 threading=multi toolset=msvc-14.0 address-model=64 --stagedir=release_64bit --build-dir=intermediate_64but release link=static,shared --with-atomic --with-thread --with-date_time --with-filesystem define=_VCRTIMP= define=_ACRTIMP=

При устранении неполадок при связывании - обратите внимание на неразрешенные __imp* имена функций из-за использования dllimport ключевого слова - и если вы ссылаетесь на libvcruntime.lib, у вас не должно быть никаких __imp* ссылок.

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

Здесь я обнаружил следующие вещи, которые позволяют запускать приложение, созданное в VS-2015.

• Загрузите распространяемый пакет с https://www.microsoft.com/en-us/download/details.aspx?id=52685
• Поместите файлы msvcp140d.dll, vccorlib140d.dll, vcruntime140d.dll и ucrtbased.dll.

Примечание. Разместите версии dll в соответствии с архитектурой процессора вашей системы (x86, x64 ..).

Настройка: Свойства конфигурации - Дополнительно - Использование MFC - «Использовать MFC в статической библиотеке» у меня сработало (с консольным приложением, а не с приложением MFC / ATL как таковым).

Если вы не пытаетесь заменить среду выполнения своей собственной, то не имеет значения,

• У вас включен / отключен набор текста во время выполнения
• У вас включены / отключены исключения C ++
• Независимо от того, настроена ли у вас библиотека времени выполнения на многопоточную DLL или нет (установка не-DLL по-прежнему встраивает ее в ваш двоичный файл)

Единственное, что вам нужно убедиться, это то, что вы не используете какие-либо его возможности и Visual Studio автоматически не связывает его. Т.е. Никаких утверждений, никаких обращений к чему-либо в string.h или stdio.h, ничего. Все, что компилятор может заменить своими собственными встроенными функциями, это нормально, как и проверки компилятора, такие как static_assert.