VC++ Распространяемый 2012 или 2013 или 2015?

Question

У меня есть приложение, написанное в QT. Раньше я использовал Visual Studio 2012 и Qt 5.3.1, после чего недавно обновился до Visual Studio 2015 и QT 5.6. Ранее я предоставлял msvcp110 и msvcr110 как часть установки (я знаю, что это была не лучшая практика, но мне это удалось).

После обновления я должен был установить VC++ 2015 из-за изменений с VS 2015. Я не против изменений и в настоящее время предоставляю пакеты-переделки для установки.

Проблема, с которой я столкнулся, заключается в том, что мне также необходимо предоставить VC++ 2012, а также недавно запустить программное обеспечение в Windows 8.1 Pro, меня также попросили предоставить VC++ 2013 (никогда не использовали VS2013 для компиляции). Диагноз был от хождения зависимостей и google. Не только это, мне пришлось установить x86 и x64 из всех трех версий VC++ для запуска программного обеспечения (даже не начинайте быть честным).

1. Зачем мне нужны VC++ 2012 и 2013, когда я использую только Visual Studio 2015?
2. Как избавиться от других пакетов-переделов? Это какой-то код, который я написал, который зависит? Если да, то я могу это выяснить?
3. Зачем мне нужно предоставлять 32-разрядные и 64-разрядные версии при компиляции строго в 64-битном компиляторе?
4. Любой способ диагностики без хождения по играм? Может ли быть некоторая регистрация, когда приложение отказывается начинать?

Извинения за длинный пост, но любой свет здесь может восстановить мое здравомыслие.

Заранее спасибо.

Answer 1

1. Вы используете DLL-соединение, связанное со старым временем выполнения. Вы можете использовать Dependency Walker на вашей машине разработки, чтобы отслеживать это, не нужно устанавливать какие-либо инструменты на машине для клиентов.

2. перенесите все файлы, поставляемые вместе с приложением к версии, построенной на VC++ 2015.

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

4. Для библиотек DLL, отличных от библиотеки времени исполнения, вы можете использовать задержку загрузки, а затем быть в состоянии уловить отказ в загрузке библиотеки. Однако вы не можете эффективно задерживать msvcr * .dll. Одним из вариантов было бы создание очень тонкого EXE, который вообще не использует DLL поддержки (либо использует чистый Win32 API, либо статически связывает среду выполнения), которая ничего не делает, кроме установки обработчика ошибок, а затем загружает вашу основную программу, которая теперь находится в форме DLL. Загрузка вашей основной DLL-программы должна выполняться либо с помощью связывания с задержкой, либо с LoadLibrary() + GetProcAddress(). Эта основная DLL программы будет бесплатной для импорта DLL исполняемых файлов, как обычно.