Szenarien für Bereitstellungsbeispiele

Artikel
09/02/2008

Aktualisiert: November 2007

Angenommen, wir haben MyApplication.exe und MyLibrary.DLL mit MFC erstellt. MyApplication.exe ist abhängig von MyLibrary.DLL, beide verwenden MFC in einer freigegebenen DLL, und beide können systemeigene oder gemischte (/clr) Binärdateien sein. Im einfachsten Fall werden beide vom Assistenten ohne Änderung der Standardeinstellungen generiert. In den Beispielen dieses Abschnitts wird beschrieben, wie diese Anwendung auf einem anderen Computer bereitgestellt wird, auf dem Visual Studio nicht installiert ist. Dieser Abschnitt bezieht sich hauptsächlich auf das Bereitstellen der Releaseversion der Anwendung; es wird jedoch auf Änderungen bei der Bereitstellung der Debugversion einer Anwendung eingegangen.

Hinweis:
Das Verteilen von Visual C++-Debugprogrammen ist unter diesem EULA nicht gestattet. Sie können diese jedoch vorübergehend zu Debugzwecken bereitstellen. Beachten Sie die Softwarelizenzbedingungen EULA für Visual Studio 2008.

Erstinstallation

In diesem Szenario sind drei Computer zu berücksichtigen.

Der Entwicklungscomputer ist der, auf dem die Anwendung erstellt wird. Darauf ist Visual Studio 2005 (STD, PRO oder TS) installiert.

Auf den beiden Bereitstellungscomputern ist Visual Studio 2005 nicht installiert. Bereitstellungsziel 1 ist ein Computer mit einem Betriebssystem, das eine manifestbasierte Bindung von Anwendungen an ihre Abhängigkeiten unterstützt (Windows XP Home Edition, Windows XP Professional, Windows Server 2003, Windows Vista). Das Betriebssystem von Bereitstellungsziel 2 unterstützt dies nicht (Windows 2000).

Ziel ist es, die Anwendung auf dem Entwicklungscomputer zu erstellen, auf den beiden Zielcomputern bereitzustellen und auszuführen.

Vorbereitung

Wenn Sie eine Visual C++-Binärdatei erstellt haben, die auf einem anderen Computer ausgeführt werden soll, müssen Sie bestimmen, von welchen DLLs diese Binärdatei abhängig ist. Ein nützliches Tool dafür ist Dependency Walker. In diesem Szenario müssen Sie die Visual C++-DLLs berücksichtigen, insbesondere CRT und MFC. Wenn Sie die Debugversion von MyApplication.exe in Visual Studio öffnen und deren Ressourcen durchsuchen, finden Sie die RT_MANIFEST-Ressource. Dies ist das in der Binärdatei eingebettete Manifest. Wenn Sie es exportieren und als XML-Datei öffnen, sehen Sie Folgendes:

<?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>

Das bedeutet, dass diese Anwendung von diesen Assemblys abhängt:

Assembly Microsoft.VC90.DebugCRT, version 9.0.xxxxx.yy for x86
Assembly Microsoft.VC90.DebugMFC, version 9.0.xxxxx.yy for x86
Assembly Microsoft.Windows.Common-Controls, version 6.0.0.0 for x86

In der Releasebinärdatei sehen Sie Folgendes:

<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>

Das bedeutet, dass diese Anwendung von diesen Assemblys abhängt:

Assembly Microsoft.VC90.CRT, version 9.0.xxxxx.yy for x86
Assembly Microsoft.VC90.MFC, version 9.0.xxxxx.yy for x86
Assembly Microsoft.Windows.Common-Controls, version 6.0.0.0 for x86

Ähnliche Manifeste würden Sie in MyLibrary.dll sowohl in der Debug- als auch in der Releaseversion sehen. Beachten Sie, dass die Manifest-ID für eine EXE 1 ist und für eine DLL 2 ist. Wenn ein Manifest nicht in der Binärdatei eingebettet ist, so wird es unter <Binärdateiname>.<Erweiterung>.manifest abgespeichert und hat denselben Inhalt.

Hinweis:
Das Erstellen von C++-Anwendungen ohne Manifest, die auf die alte Weise mit %PATH% an Visual C++-Bibliotheken gebunden werden, wird in Visual Studio 2005 nicht unterstützt. Außerdem können Visual C++-DLLs dies feststellen, das Laden der DLL verhindern und das nicht unterstützte Szenario sowie die erforderlichen Änderungen melden. Verwenden Sie nicht /manifest:no, und löschen Sie nicht das Manifest.

Das Erstellen von C++-Anwendungen ohne Manifest, die auf die alte Weise mit %PATH% an Visual C++-Bibliotheken gebunden werden, wird in Visual Studio 2005 nicht unterstützt. Außerdem können Visual C++-DLLs dies feststellen, das Laden der DLL verhindern und das nicht unterstützte Szenario sowie die erforderlichen Änderungen melden. Verwenden Sie nicht /manifest:no, und löschen Sie nicht das Manifest.

Bereitstellungsmethoden

In diesem Beispiel installieren Sie MyApplication.exe in einem Ordner %TARGET%, der während der Installation vom Benutzer angegeben werden kann. MyLibrary.dll wird in %TARGET%\MyLibrary installiert und \MyLibrary dem Pfad hinzugefügt.

Wir untersuchen zwei Methoden zum Bereitstellen von VC++-Anwendungen:

Das Erstellen eines Setuppakets mithilfe eines Setup- und Bereitstellungsprojekts.
Bereitstellung mit XCopy.

Für jede Methode erforschen wir zwei Szenarien:

Das Bereitstellen von Visual C++-Bibliotheken als freigegebene Assemblys.
Das Bereitstellen von Visual C++-Bibliotheken als private Assemblys.

In Szenario 1 gibt es nur eine Kopie der Visual C++-DLLs im Ordner WinSxS. In Szenario 2 gibt es zwei Kopien der Visual C++-DLLs: Eine wird im lokalen Ordner der EXE und eine im lokalen Ordner der DLL der Anwendung installiert.

Hinweis:
Szenario 2 wird unter Windows 2000 nicht unterstützt, da das Bereitstellen in lokalen Anwendungsordnern Probleme bei der Wartung verursacht.

Siehe auch

Aufgaben

Gewusst wie: Bereitstellen eines Setup- und Bereitstellungs-Projekts

Gewusst wie: Bereitstellen mit XCopy

Konzepte

Bereitstellungsbeispiele

Freigeben über