Сценарии для примеров развертывания
Обновлен: Ноябрь 2007
Предположим, существует приложение MyApplication.exe и библиотека MyLibrary.DLL, созданные с помощью MFC. MyApplication.exe зависит от MyLibray.DLL, оба файла используют MFC в общей DLL и оба файла могут быть неуправляемыми или смешанными двоичными файлами (/clr). В самом простом случае оба файла создаются мастером без изменения параметров по умолчанию. В примерах этого раздела описывается, как производить развертывание приложения на другом компьютере, на котором не установлена среда Visual Studio. В этом разделе в основном описывается развертывания версий выпуска приложения, однако также отмечены изменения, необходимые для развертывания отладочной версии приложения.
![]() |
---|
Повторное распространение отладочных программ Visual C++ не разрешается данным лицензионным соглашением. Однако можно проводить временное развертывание этих программ в целях отладки. См. лицензионное соглашение (EULA) для Visual Studio 2008. |
Начальная настройка
В этом сценарии существует три компьютера, которые будут рассматриваться.
Компьютер разработчика — компьютер, на котором создается приложение. На нем установлена среда Visual Studio 2005 (версия STD, PRO или TS).
На двух целевых компьютерах, на которых производится развертывание, среда Visual Studio 2005 не установлена. Цель развертывания 1 — компьютер под управлением операционной системы, поддерживающей привязку приложений к их зависимостям на основе манифестов (Windows XP Home Edition, Windows XP Professional, Windows Server 2003, Windows Vista). На цели развертывания 2 установлена операционная система, не поддерживающая подобную привязку (Windows 2000).
Задача состоит в том, чтобы построить приложение на компьютере разработчика, выполнить развертывание на двух целевых компьютерах и запустить его.
Подготовка
После создания двоичного файла Visual C++, который будет запускаться на другом компьютере, необходимо определить от каких библиотек DLL он зависит. Для этих целей удобно использовать средство Dependency Walker. В этом сценарии необходимо учитывать библиотеки DLL Visual C++, в частности CRT и MFC. Если открыть отладочную версию MyApplication.exe в Visual Studio и просмотреть ресурсы приложения, можно увидеть ресурс RT_MANIFEST. Этот манифест внедрен в двоичный файл. Если его экспортировать и открыть в виде XML-файла, отобразится следующее:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.DebugCRT" version="9.0.xxxxx.yy" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.DebugMFC" version="9.0.xxxxx.yy" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>
Это означает, что эта сборка зависит от следующих сборок.
Сборка Microsoft.VC90.DebugCRT, версия 9.0.xxxxx.yy для x86
Сборка Microsoft.VC90.DebugMFC, версия 9.0.xxxxx.yy для x86
Сборка Microsoft.Windows.Common-Controls, версия 6.0.0.0 для x86
В версии выпуска двоичного файла можно увидеть следующее:
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.xxxxx.yy" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.MFC" version="9.0.xxxxx.yy" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>
Это означает, что эта сборка зависит от следующих сборок.
Сборка Microsoft.VC90.CRT, версия 9.0.xxxxx.yy для x86
Сборка Microsoft.VC90.MFX, версия 9.0.xxxxx.yy для x86
Сборка Microsoft.Windows.Common-Controls, версия 6.0.0.0 для x86
Аналогичные манифесты можно увидеть в MyLibrary.dll для отладочной версии и для версии выпуска. Обратите внимание, что идентификатор манифеста для EXE-файла равен 1, а для DLL — 2. Также, если манифест не внедрен в двоичный файл, он сохраняется как <имя_двоичного_файла>.<расширение>.manifest с тем же содержимым.
![]() |
---|
Среда Visual Studio 2005 не поддерживает построение приложений C++ без манифеста и привязку к библиотекам Visual C++ старым методом с помощью %PATH%. Кроме того, библиотеки DLL Visual C++ могут обнаружить это, остановить загрузку DLL и выдать сообщение о неподдерживаемом сценарии и необходимых изменениях. Не следует использовать параметр /manifest:no или удалять манифест. |
Методы развертывания
В этом примере приложение MyApplication.exe устанавливается в папку %TARGET%, которую может указать пользователь во время установки. MyLibrary.dll устанавливается в папку %TARGET%\MyLibrary, а каталог \MyLibrary добавляется к пути.
Рассмотрим два метода развертывания приложений VC++.
Построение пакета установки с помощью проекта установки и развертывания.
Развертывание XСopy.
Для каждого метода рассматриваются два сценария.
Развертывание библиотек Visual C++ как общих сборок.
Развертывание библиотек Visual C++ как закрытых сборок.
В сценарии 1 есть только одна копия библиотек DLL Visual C++ в папке WinSxS. В сценарии 2 есть две копии библиотек DLL Visual C++, установленные в локальных папках EXE-файла и DLL-файла.
![]() |
---|
Сценарий 2 не поддерживается в операционных системах Windows 2000, так как развертывание в папках, локальных для приложения, создает проблемы при обслуживании. |
См. также
Задачи
Практическое руководство. Развертывание проекта установки и развертывания
Практическое руководство. Развертывание с помощью Xcopy