Включая среду выполнения MS C ++ в VS2005, сгенерированном MSI

Question

У меня есть проект, который зависит от конкретной версии MSVCR80.dll (среда выполнения MS Visual C), и я сталкиваюсь с проблемами, когда в зависимости от конкретной конфигурации системы мое приложение не всегда получает правильная версия этого файла. Что за путь, по которому нужно найти файл с таким именем, было немного глупо, и это не всегда правильно ...

Есть ли способ при создании проекта развертывания в VS2005 гарантировать , что мое приложение будет всегда использовать предоставленную мной среду выполнения? Когда я добавляю исполняемый файл в проект, он спрашивает о создании модуля слияния ... но не совсем уверен, что он делает. И независимо от его создания проблема остается.

Answer 1

Мартин Рихтер написал статью об этом в CodeProject: Легко создавайте проекты с частными сборками MFC, ATL и CRT

Это решение опирается не на ваши пакеты MSI, а на приложение, использующее файлы CRT.

Answer 2

Я не уверен, что ваше приложение после установки не работает или это dll, который вы используете как часть установки, которая не работает?

Чтобы сделать очень длинную историю, очень короткую: новые версии сред выполнения C / C ++ устанавливаются как сборки Win32 или параллельная установка. Это означает, что файлы будут помещаться в папки в C: \ Windows \ winsxs - , эквивалентном Win32 GAC , и здесь могут сосуществовать несколько версий одного и того же файла.

Приложения, скомпилированные с помощью Visual Studio 2005/2008 , поместят файл манифеста в двоичный файл, и этот манифест указывает , какую версию среды выполнения для параллельной работы привязать к . Неважно, если вы поместите MSVCR80.dll рядом с вашим EXE или даже в system32 - встроенный в EXE манифест загрузит файл из C: \ Windows \ winsxs .

Это все "полный круг". В прежние времена время работы шло к System32. Это вызвало первоначальную dll-ад : приложения перезаписывали глобальные файлы времени выполнения друг друга. Чтобы исправить все это, идея заключалась в том, чтобы «изолировать изменения» для каждого приложения. Следовательно, новый подход состоял в том, чтобы изолировать локальную копию исполняемого файла рядом с EXE. Теперь это вызвало совершенно новую проблему: как убедиться, что обновления безопасности для изолированной DLL были развернуты? В большинстве случаев этого никогда не происходило, и у вас было много приложений, работающих с локальными небезопасными dll. Так что делать? Было принято решение представить второе пришествие dll-hell: метод параллельной сборки. При таком подходе среды выполнения не локальные, а глобальные - с критической разницей в поддержке параллельной установки. Таким образом, теоретически приложения могут функционировать без перезаписи библиотек времени выполнения друг друга.

Итак, вот краткое изложение ", как сделать развертывание во время выполнения сложным ". Я не уверен, что это все еще возможно сделать, но вы проверили, можете ли вы статически связать со временем выполнения ? Иногда старой школе действительно легче ...