Мы распределяем среды выполнения Visual C ++ как частные сборки (т. Е. Помещаем msvcp90.dll, msvcm90.dll, msvcr90.dll и Microsoft.VC90.CRT.manifest в Microsoft.VC90. Папка CRT, которая существует в том же каталоге, что и исполняемый файл нашего приложения). До сих пор на каждой не-dev машине (несколько сотен) это было нормально. Однако я обнаружил одну конкретную проблемную машину, которая не может найти эти сборки.
Они используют XP, поэтому, когда они пытаются запустить наше приложение, они получают сообщение :
Это приложение не удалось запустить, потому что приложение
конфигурация неверна. Переустановка приложения может исправить это
проблема.
Я заставил их запустить Dependency Walker в exe нашего приложения, и это указало, что оно не может найти msvcp90.dll или msvcr90.dll. Затем я попросил их отследить содержимое каталога нашего приложения, что показало, что эти «недостающие» библиотеки DLL были на самом деле там, где они должны быть (внутри каталога Microsoft.VC90.CRT рядом с exe-файлом), но, тем не менее, в приложении просто не находит их при запуске.
В крайнем случае, у меня есть установка перераспределяемых файлов напрямую, но это в основном только для устранения неполадок, так как мы предпочли бы продолжать распространять библиотеки DLL без дополнительного установщика (наше приложение можно просто запустить без установки).
Возможно, мне следует включить собственный манифест нашего приложения:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="OurApp.Name" type="win32"/>
<description>Our App Description</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b">
</assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>
Редактировать: Ранее я упоминал, что не было dependentAssembly, но я понял, что он генерируется, поэтому приведенный выше манифест отражает фактический манифест, который он создает.
Что может заставить программу просто не находить эти зависимости? Она прекрасно находит их на многих других компьютерах, большинство из которых никогда раньше не видели этих сред выполнения. Я, вероятно, испортил что-то простое (скорее всего, в моем манифесте), но пока он работает нормально на 99% клиентских компьютеров.
В качестве бонуса эта статья представляет собой краткое изложение частных сборок, но пока она не помогла мне решить некоторые проблемы.
Обновление: после перемещения библиотек DLL в тот же каталог, что и EXE, он все равно не запустился. Затем, после установки распространяемых файлов , он запустился нормально. Похоже, что он либо не просматривал локальные каталоги, либо по какой-то причине посчитал локальные библиотеки DLL неприемлемыми.