Windows Bewährte Methoden für den Installer

In diesem Abschnitt wird eine Liste der Tipps aufgeführt, die mit der Hauptdokumentation Windows Installer SDK verknüpft sind, um Anwendungsentwickler, Setupautoren, IT-Experten und Infrastrukturentwickler bei der Ermittlung bewährter Methoden für die Verwendung des Windows Installers zu unterstützen:

Aktualisieren Sie die Version des Windows Installers.

  • Verwenden Sie Windows Installer 5.0 auf Windows Server 2008 R2 und Windows 7. Dies ist die Windows Installer-Version, die mit dem Betriebssystem bereitgestellt wird.
  • Verwenden Sie Windows Installer 4.5 auf Windows Server 2008, Windows Server 2003 mit Service Pack 1 (SP1), Windows Vista mit Service Pack 1 (SP1) oder Windows XP mit Service Pack 2 (SP2). Informationen zum Abrufen der aktuellen Version Windows Installers finden Sie unter Windows Installer Redistributables.
  • Verwenden Sie Windows Installer 3.1 unter Windows 2000 mit Service Pack 3 (SP3). Windows Die Installationsprogrammversion 3.1 verfügt über Features, die eine bessere Anwendungswartung und das Patchenvon ermöglichen.
  • Viele wichtige Features wurden mit Version 3.0 eingeführt und sind im Abschnitt Nicht unterstützt in Windows Installer Version 2.0aufgeführt. Installationspakete und Updates, die für Windows Installer 2.0 erstellt wurden, können mit Windows Installer 3.0 und höher installiert werden. Patchpakete, die die neuen Tabellen enthalten, die von Windows Installer 3.0 verwendet werden, können weiterhin mit früheren Versionen von Windows Installer angewendet werden, jedoch ohne die Patchfunktionen von Windows Installer 3.0. Es ist auch möglich, Patches zu erstellen, die explizit die Windows Installer 3.0 erfordern, die von früheren Versionen von Windows Installer nicht angewendet werden können. Wenn ein Benutzer die Installationsprogrammversion nicht aktualisieren kann, stellen Sie sicher, dass Die Anwendung oder das Update mit einem zukünftigen Update des Windows Installers kompatibel ist.
  • Eine Liste der Windows Installer-Funktionen, die von früheren Versionen des Windows Installers nicht unterstützt werden, finden Sie unter Neuerungen in Windows Installer.

Erfüllen Sie die Windows Logo-Zertifizierungsanforderungen.

  • Auch wenn Sie Ihre Anwendung nicht an das Logo-Programm übermitteln möchten, können Sie die Richtlinien für die Logozertifizierung befolgen, um ihr Windows Installer-Paket zu verbessern. Eine Übersicht über die Logoanforderungen und Links zu bestimmten Logozertifizierungsprogrammen finden Sie unter Windows Installer und Logoanforderungen.

Bereiten Sie das Paket für die Lokalisierung vor.

  • Es ist eine bewährte Methode, sich beim Erstellen des ursprünglichen Installationspakets auf die zukünftige Lokalisierung vorzubereiten. Sie können das vorgeschlagene Verfahren zur Paketlokalisierung unter Lokalisieren eines Windows Installer-Paketsbefolgen.

Aktualisieren Sie Die Entwicklungstools und Dokumentation für Windows Installer.

  • Die entwicklungstools für Windows Installer sind nicht weitervertrenbar, und Sie sollten nur die Von Microsoft verfügbaren Versionen dieser Tools verwenden. Diese sind in den Windows SDK-Komponenten für Windows Installer-Entwickler im Microsoft Windows Software Development Kit (SDK) verfügbar.
  • Mehrere unabhängige Softwarehersteller bieten Tools zum Erstellen oder Ändern Windows Installer-Pakete an. Diese Tools können eine Paketerstellungsumgebung bereitstellen, die möglicherweise einfacher zu verwenden ist als die Tools, die im Windows Installer SDK bereitgestellt werden. Weitere Informationen zu diesen Tools finden Sie in den Informationsressourcen, die unter Andere Quellen von Windows Installer-Informationenerläutert werden.
  • Die Möglichkeit, ein Paket aus Textdateien zu erstellen, kann für einige Entwickler intuitiver sein. Das auf Sourceforge.net verfügbare WiX-Toolset (Windows Installer XML) erstellt Windows Installationspakete aus XML-Quellcode.
  • Die Dokumentation im Windows Installer SDK, das in der MSDN Online Library veröffentlicht wurde, wird am häufigsten aktualisiert.
  • Verwenden Sie die aktuelle Version von Msizap.exe (Version 3.1.4000.2726 oder höher), die in den Windows SDK-Komponenten für Windows Installer Developers for Windows Vista oder höher verfügbar ist. Kleinere Versionen von Msizap.exe können Informationen zu allen Updates entfernen, die auf andere Anwendungen auf dem Computer des Benutzers angewendet wurden. Wenn diese Informationen entfernt werden, müssen diese anderen Anwendungen möglicherweise entfernt und neu installiert werden, um zusätzliche Updates zu erhalten.
  • Der Datenbanktabellen-EditorOrca.exe ist ein Datenbanktabellen-Editor zum Erstellen und Bearbeiten von Windows Installer-Paketen und Mergemodulen. Sie verfügt über eine einfache GUI-Schnittstelle, unterstützt aber die erweiterte Bearbeitung von Windows Installer-Datenbanken. Auch wenn Sie eine andere Anwendung als primäres Entwicklungstool verwenden, ist die Verwendung von Orca.exe bei der Problembehandlung und beim Testen eines Pakets praktisch.
  • Informationen zu aktuellen Windows Installer, die in Blogs, technischen Chats, Newsgroups, technischen Artikeln und Websites verfügbar sind, finden Sie unter Weitere Quellen für Windows Installer-Informationen.

Wenn Sie sich dafür entscheiden, eine ältere Setupanwendung neu zu packen, befolgen Sie die bewährten Methoden für das Erneute Packen.

Viele Anwendungsanbieter stellen native Windows Installer-Pakete für die Installation oder ihre Produkte bereit. Software, die eine vorhandene Legacy-Setupanwendung in ein Windows Installer-Paket konvertiert, wird als Tool zum Erneuten Packen bezeichnet. Das Whitepaper Step-by-Step Guide to Creating Windows Installer Packages and Repackaging Software for the Windows Installer (Schrittweise Anleitung zum Erstellen von Windows Installer-Paketen und Neupaketieren von Software für den Windows Installer) beschreibt ein kommerziell verfügbares Tool zum Neupaketen. Das Erneute Packen einer vorhandenen Setupanwendung ist nicht die bewährte Methode für die Entwicklung. Anwendungen, die von Anfang an entwickelt wurden, um Windows Installer-Features zu nutzen, können für Benutzer einfacher zu installieren und zu warten sein. Wenn Sie sich für die Verwendung einer Neupaketsoftware entscheiden, können Sie mithilfe der folgenden Methoden ein besseres Windows Installer-Paket erstellen.

  • Neupakettools konvertieren Legacyinstallationen in ein Windows Installer-Paket, indem sie vor und nach der Installation ein Bild von einem Stagingsystem machen. Alle Registrierungsänderungen, Dateiänderungen oder Systemeinstellungen, die während des Aufzeichnungsprozesses auftreten, sind in der Installation enthalten. Konfigurieren Sie die Hardware und Software des Computers, der zum erneuten Packen der Installation verwendet wird, so nah wie möglich am System des vorgesehenen Benutzers. Erstellen Sie ein separates Paket für jede andere Hardwarekonfiguration. Erneutes Packen mithilfe eines sauberen Stagingcomputers. Entfernen Sie alle unnötigen Anwendungen. Beenden Sie alle unnötigen Prozesse. Schließen Sie alle nicht wesentlichen Systemdienste.
  • Erstellen Sie immer eine Kopie der ursprünglichen Installation, bevor Sie damit beginnen, sie zu bearbeiten. Arbeiten Sie immer an der Kopie. Beenden Sie ein Erneutes Packen niemals, bevor die Paketerstellung abgeschlossen ist. Wenn das Umpacken das Paket beschädigt, verfügen Sie weiterhin über das originale Paket.
  • Packen Sie Microsoft-Softwareupdates nicht erneut in ein Windows Installer-Paket. Microsoft veröffentlicht Softwareupdates wie Service Packs als selbstextrahierende Dateien, die die Installation automatisch durchführen. Diese Updates verwenden andere Installationsprogramme als das Windows Installer, um geschützte Windows Ressourcen zu ersetzen, und können nicht in ein Windows Installer-Paket konvertiert werden. Informationen zum Bereitstellen Windows Service Packs finden Sie im Service Pack-Bereitstellungshandbuch auf Microsoft TechNet.
  • Verwenden Sie kein Neupakettool, um ein Windows Installer-Paket in ein neues Paket zu konvertieren. Der Windows Installer fügt Dem System und den Anwendungsressourcen Konfigurationsinformationen hinzu. Wenn ein Neupakettool das System vor und nach der Installation vergleicht, interpretiert der Neupaketierer die Konfigurationsinformationen als Teil der Anwendung falsch. Dadurch wird in der Regel die neu gepackte Anwendung beschädigt. Verwenden Sie stattdessen Anpassungstransformationen, um ein vorhandenes Windows Installer-Paket zu ändern oder ein neues Paket zu erstellen. Sie können Anpassungstransformationen mit dem Msitran.exe-Tool erstellen.
  • Verwenden Sie kein Tool zum erneuten Packen, um mehrere Windows Installer-Pakete in einem einzelnen Paket zu konsolidieren. Stattdessen können Sie das tool Msistuff.exe verwenden, um die ausführbare Datei Setup.exe Bootstrap so zu konfigurieren, dass die Pakete nacheinander installiert werden.
  • Erstellen Sie Windows Installer-Paket, damit es vom Kunden problemlos angepasst werden kann. Globale Variablen, die vom Windows Installer während einer Installation verwendet werden, können mithilfe öffentlicher Eigenschaften oder Anpassungstransformationen festgelegt werden. Stellen Sie Dokumentation für die Verwendung dieser Eigenschaften und praktische Standardwerte für alle anpassbaren Werte zur Verfügung. Informationen zum Abrufen und Festlegen von Eigenschaften finden Sie unter Verwenden von Eigenschaften. Ein Beispiel für eine Anpassungstransformation finden Sie unter Beispiel für eine Anpassungstransformation.

Versuchen Sie nicht, geschützte Ressourcen zu ersetzen.

Windows Installerpakete sollten nicht versuchen, geschützte Ressourcen während der Installation oder des Updates zu ersetzen. Der Windows Installer entfernt oder ersetzt diese Ressourcen nicht, da Windows das Ersetzen wichtiger Systemdateien, Ordner und Registrierungsschlüssel verhindert. Der Schutz dieser Ressourcen verhindert Anwendungs- und Betriebssystemfehler.

  • Bei der Ausführung auf Windows Server 2008 oder Windows Vista überspringt der Windows-Installer die Installation von Dateien oder Registrierungsschlüsseln, die durch Windows Resource Protection (WRP) geschützt sind. Das Installationsprogramm gibt eine Warnung in die Protokolldatei ein und fährt mit dem Rest der Installation ohne Fehler fort. Weitere Informationen finden Sie unter Using Windows Installer and Windows Resource Protection.
  • WRP ist der neue Name für Windows File Protection (WFP). WRP schützt Registrierungsschlüssel und Ordner sowie wichtige Systemdateien. In Windows Server 2003, Windows XP und Windows 2000, als der Windows Installer eine WFP-geschützte Datei gefunden hat, fordert das Installationsprogramm an, dass WFP die Datei installiert. Weitere Informationen finden Sie unter Using Windows Installer and Windows Resource Protection.

Verlassen Sie sich nicht auf nicht kritische Ressourcen.

Die Installation oder das Update sollte aus den folgenden Gründen nicht von der Installation nicht kritischer Ressourcen abhängen.

  • Benutzerdefinierte Aktionen können fehlschlagen, wenn sie von einer Komponente abhängen, die zu einem Feature gehört, das der Benutzer anklickt und nicht installiert.
  • Benutzerdefinierte Aktionen, die vor der InstallFinalize-Aktion sequenziert wurden, können fehlschlagen, wenn sie von einer Komponente abhängen, die eine assembly enthält, die installiert wird. Der Windows Installer führt erst dann einen Commit für Assemblys in den globalen Assemblycache (GAC) durch, wenn die InstallFinalize-Aktion abgeschlossen ist.

Verwenden Sie die API, um Windows Installer-Konfigurationsinformationen abzurufen.

Die Installation Ihrer Anwendung oder Ihres Updates sollte nicht vom direkten Zugriff auf Windows Installer-Konfigurationsinformationen abhängig sein, die auf Ihrem Computer gespeichert sind. Verwenden Sie stattdessen die Windows Installer-Anwendungsprogrammierschnittstelle, um Konfigurationsinformationen abzurufen. Der Speicherort und das Format der Konfigurationsinformationen werden vom Windows Installer-Dienst verwaltet und können sich ändern.

Organisieren Sie die Installation Ihrer Anwendung um Komponenten herum.

Der Windows Installer-Dienst installiert oder entfernt Sammlungen von Ressourcen, die als Komponenten bezeichnet werden. Da Komponenten häufig freigegeben werden, muss der Autor eines Installationspakets regeln, wenn die Komponenten eines Features oder einer Anwendung angegeben werden.

  • Befolgen Sie die Komponentenregeln beim Organisieren von Anwendungen in Komponenten, um sicherzustellen, dass neue Komponenten oder neue Versionen von Komponenten installiert und entfernt werden können, ohne dass andere Anwendungen beschädigt werden. Sie können das unter Definieren von Installerkomponenten beschriebene Verfahren befolgen.
  • Das Installationsprogramm verfolgt jede Komponente mit der entsprechenden Komponenten-ID-GUID nach, die in der Komponententabelle angegeben ist. Für den Betrieb des Referenzzählmechanismus des Windows Installers ist es wichtig, dass die Komponenten-ID-GUID korrekt ist. Befolgen Sie die Richtlinien unter Ändern des Komponentencodes.
  • Wenn Ihr Paket die Komponentenregeln nicht einhalten muss, beachten Sie die möglichen Konsequenzen, und stellen Sie sicher, dass Ihre Installation diese Komponenten niemals installiert, wo sie Komponenten auf dem System des Benutzers beschädigen können. Weitere Informationen finden Sie unter Was geschieht, wenn die Komponentenregeln verletzt werden?.
  • Beachten Sie, wie der Windows Installer beim Ersetzen vorhandener Dateien die Dateiversionsregeln an wendet. Der Windows Installer bestimmt zunächst, ob die Schlüsseldatei der Komponente bereits installiert ist, bevor versucht wird, eine der Dateien der Komponente zu installieren. Wenn das Installationsprogramm eine Datei mit dem gleichen Namen wie die Schlüsseldatei der Komponente findet, die am Zielspeicherort installiert ist, vergleicht es Version, Datum und Sprache der beiden Schlüsseldateien und verwendet Dateiversionsregeln, um zu bestimmen, ob die vom Paket bereitgestellte Komponente installiert werden soll. Wenn das Installationsprogramm feststellt, dass die Komponentenbasis auf der Schlüsseldatei ersetzt werden muss, verwendet es die Dateiversionsregeln für jede installierte Datei, um zu bestimmen, ob die Datei ersetzt werden soll.

Reduzieren Sie die Größe von großen Windows Installer-Paketen.

Sehr große Windows Pakete nehmen Systemressourcen und können für Benutzer schwierig zu installieren sein. Es ist eine bewährte Methode, die Größe sehr großer Installationspakete Windows folgenden Methoden zu reduzieren.

  • Komprimieren Sie die Dateien in der Installation, und speichern Sie sie in einer .cab Datei . Mit dem Installer kann .cab Datei als separate externe Datei oder als Datenstrom im MSI-Paket selbst gespeichert werden. Weitere Informationen finden Sie unter Verwenden von Schränken und komprimierten Quellen.
  • Entfernen Sie verschwendeten Speicherplatz in der .msi-Datei, indem Sie eine der Optionen verwenden, die unter Reduzieren der Größe einer .msi werden.
  • Wenn Ihr Windows Installer-Paket mehr als 32767 Dateien enthält, müssen Sie das Schema der Datenbank ändern. Weitere Informationen finden Sie unter Erstellen eines großen Pakets.

Wenn Sie benutzerdefinierte Aktionen verwenden, befolgen Sie die bewährten Methoden für benutzerdefinierte Aktionen.

Der Windows Installer verfügt über viele integrierte Standardaktionen für die Installation und Wartung von Anwendungen. Entwickler sollten versuchen, sich so weit wie möglich auf die Standardaktionen zu verlassen, anstatt ihre eigenen benutzerdefinierten Aktionen zu erstellen. Es gibt jedoch Situationen, in denen der Entwickler eines Installationspakets es für erforderlich hält, eine benutzerdefinierte Aktion zu schreiben.

Wenn Sie Assemblys verwenden, befolgen Sie bewährte Assemblymethoden.

Wenn Ihr Paket Softwareassemblys verwendet,befolgen Sie die Richtlinien zum Hinzufügen von Assemblys zu einem Paket,Aktualisieren von Assemblysund Installieren und Entfernen von Assemblys.

Versenden Sie keine gleichzeitigen Installationen.

Bei gleichzeitigenInstallationen , auch geschachtelte Installationen genannt, wird während einer derzeit ausgeführten Installation ein Windows Installer-Paket installiert. Die Verwendung gleichzeitiger Installationen ist keine bewährte Methode, da sie für Kunden schwierig zu bedienen sind. Patchen und Upgraden funktionieren bei gleichzeitigen Installationen möglicherweise nicht. Die empfohlene Alternative zur Verwendung gleichzeitiger Installationen besteht darin, stattdessen eine Setupanwendung und einen externen Ui-Handler zu verwenden, um mehrere Windows Installer-Pakete sequenziell zu installieren.

Weitere Informationen zur Verwendung eines externen Ui-Handlers finden Sie unter Überwachen einer Installation mithilfe von MsiSetExternalUI. Weitere Informationen zur Verwendung eines datensatzbasierten externen Handlers finden Sie unter Überwachen einer Installation mithilfe von MsiSetExternalUIRecord.

Gleichzeitige Installationen werden manchmal in kontrollierten Unternehmensumgebungen verwendet, um Anwendungen zu installieren, die nicht für die Öffentlichkeit bestimmt sind. Befolgen Sie diese Richtlinien, wenn Sie gleichzeitige Installationen verwenden möchten.

  • Verwenden Sie keine gleichzeitigen Installationen, um ein Versandprodukt zu installieren oder zu aktualisieren.
  • Gleichzeitige Installationen sollten keine Komponenten gemeinsam nutzen.
  • Eine Administratorinstallation sollte keine gleichzeitige Installation enthalten.
  • Integrierte ProgressBars sollten nicht mit gleichzeitigen Installationen verwendet werden.
  • Ressourcen, die angekündigt werden sollen, sollten nicht von einer gleichzeitigen Installation installiert werden.
  • Ein Paket, das eine gleichzeitige Installation einer Anwendung ausführt, sollte auch die gleichzeitige Anwendung deinstallieren, wenn das übergeordnete Produkt deinstalliert wird. Eine geschachtelte Installation befindet sich im Kontext des übergeordneten Produkts im Systemsteuerung Software.

Halten Sie Paketnamen und Paketcodes konsistent.

Der .msi-Datei kann ein beliebiger Name gegeben werden, mit dem Benutzer das Paket identifizieren können. Der Name sollte jedoch nicht geändert werden, ohne auch den Produktcode zu ändern.

  • Geben Sie ihrer .msi-Datei einen benutzerfreundlichen Namen, mit dem der Benutzer den Inhalt des Windows Installer-Pakets identifizieren kann.
  • Der Produktcode ist die Hauptidentifikation einer Anwendung und muss sich ändern, wenn eine umfassende Aktualisierung der Anwendung erfolgt. Weitere Informationen finden Sie unter ProductCode und Ändern des Produktcodes. Das Ändern des Namens der .msi Datei der Anwendung gilt als umfassende Änderung und erfordert immer eine entsprechende Änderung des Produktcodes, um die Konsistenz aufrechtzuerhalten.
  • Der Paketcode ist der primäre Bezeichner, der vom Installationsprogramm verwendet wird, um das richtige Paket für eine bestimmte Installation zu suchen und zu überprüfen. Keine zwei nichtidentischen .msi Dateien sollten jemals den gleichen Paketcode aufweisen. Wenn ein Paket geändert wird, ohne den Paketcode zu ändern, verwendet das Installationsprogramm das neuere Paket möglicherweise nicht, wenn für das Installationsprogramm noch auf beide zugegriffen werden kann. Der Paketcode wird in der Revision Number Summary-Eigenschaft des Zusammenfassungsinformationsdatenstromsgespeichert.
  • Beachten Sie, dass Die Buchstaben in den GUIDs für Produktcode und Paketcode groß geschrieben sein müssen.

Verwenden Sie nicht die Tabellen SelfReg und TypeLib.

  • Installationspaketautoren wird dringend davon abgeraten, die Selbstregistrierung und die SelfReg-Tabelle zu verwenden. Stattdessen sollten Sie Module registrieren, indem sie eine oder mehrere Tabellen in der Registrierungstabellengruppe erstellen. Viele der Vorteile des Windows Installers gehen bei der Selbstregistrierung verloren, da Routinen für die Selbstregistrierung dazu tendieren, wichtige Konfigurationsinformationen auszublenden. Eine Liste der Gründe für die Vermeidung der Selbstregistrierung finden Sie in der SelfReg-Tabelle.
  • Installationspaketautoren wird dringend davon abgeraten, die TypeLib-Tabelle zu verwenden. Anstatt die TypeLib-Tabelle zu verwenden, registrieren Sie Typbibliotheken mithilfe der Registrierungstabelle. Wenn bei einer Installation mit der TypeLib-Tabelle ein Fehler auftritt und ein Rollback ausgeführt werden muss, wird der Computer möglicherweise nicht in dem Zustand wiederhergestellt, der vor dem Rollback vorhanden war.

Geben Sie die Option zum Installieren ohne Benutzeroberfläche an.

Administratoren bevorzugen häufig die Bereitstellung von Anwendungen innerhalb eines Unternehmens, ohne dass eine Benutzerinteraktion erforderlich ist. Es ist eine bewährte Methode, es Ihrer Anwendung zu ermöglichen, die Option zur Installation mit der Benutzeroberflächesebene "None" bereitzustellen.

  • Verwenden Sie öffentliche Eigenschaften für Konfigurationsinformationen. Administratoren können diese Informationen über die Befehlszeile bereitstellen.
  • Es ist nicht erforderlich, dass die Installation von Informationen abhängig ist, die aus der Benutzerinteraktion mit Dialogfeldern gesammelt wurden. Diese Informationen sind während einer automatischen Installation nicht verfügbar.
  • Starten Sie den Computer des Benutzers während einer unbeaufsichtigten Installation nicht automatisch neu.
  • Administratoren können die Ebene der Benutzeroberfläche bei der Installation mithilfe der Befehlszeilenoption "/q" festlegen. Die Benutzeroberflächenebene kann auch programmgesteuert mit einem Aufruf von MsiSetInternalUIfestgelegt werden.

Vermeiden Sie die Verwendung der AlwaysInstallElevated-Richtlinie.

Wenn die AlwaysInstallElevated-Richtlinie nicht festgelegt ist, werden anwendungen, die nicht vom Administrator verteilt werden, mit den Berechtigungen des Benutzers installiert, und nur verwaltete Anwendungen erhalten erhöhte Rechte. Durch Das Festlegen dieser Richtlinie wird Windows Installer anweisen, systemberechtigungen zu verwenden, wenn die Anwendung auf dem System installiert wird. Diese Methode kann einen Computer mit einem Sicherheitsrisiko öffnen, da ein Benutzer ohne Administratorrechte Installationen mit erhöhten Rechten ausführen und auf sichere Speicherorte auf dem Computer zugreifen kann, wenn diese Richtlinie festgelegt ist. Es ist eine bewährte Methode, eine andere Methode als die AlwaysInstallElevated-Richtlinie zu verwenden, wenn Sie ein Paket mit erhöhten Rechten für einen Nichtadministrator installieren oder Per-User verwaltete Anwendungen patchen.

Aktivieren Sie die Richtlinie DisableMedia, um die nicht autorisierte Installation einzuschränken.

Die DisableMedia-Richtlinie kann eine nicht autorisierte Installation von Anwendungen verhindern. Wenn diese Richtlinie aktiviert ist, werden Benutzer und Administratoren, die eine Wartungsinstallation eines Produkts ausführen, daran gehindert, das Dialogfeld Durchsuchen zum Durchsuchen von Medienquellen wie CD-ROM für die Quellen anderer installierbarer Produkte zu verwenden. Das Suchen nach anderen Produkten wird unabhängig davon verhindert, ob die Installation mit erhöhten Rechten erfolgt. Es ist weiterhin möglich, dass der Benutzer das Produkt über Medien neu installiert, wenn der Benutzer über eine ordnungsgemäß bezeichnete Medienquelle verfügt.

Halten Sie die ursprünglichen Paketquelldateien sicher und für Benutzer verfügbar.

In einigen Fällen kann die ursprüngliche Quelle des Windows Installer-Pakets erforderlich sein, um eine Anwendung bei Bedarf zu installieren, zu reparieren oder zu aktualisieren. Wenn das Installationsprogramm keine verfügbare Quelle finden kann, wird der Benutzer aufgefordert, Medien bereitzustellen oder zu einem Netzwerkspeicherort zu wechseln, der die erforderlichen Quellen enthält. Es empfiehlt sich, sicherzustellen, dass das Installationsprogramm über die benötigten Quellen verfügt, ohne den Benutzer dazu auffordern zu müssen.

  • Verwenden Sie digitale Signaturen und externe Cab-Dateien, um sicherzustellen, dass die vom Installationsprogramm verwendeten Origialquellen sicher sind. Ein nicht komprimiertes Quellimage, das an einem öffentlichen Speicherort gespeichert ist, ist nicht sicher.
  • Fügen Sie eine vollständige Liste der Netzwerk- oder URL-Quellpfade zum Installationspaket der Anwendung in die SOURCELIST-Eigenschaft ein.
  • Verwenden Sie eine verteiltes Dateisystem -Freigabe (DFS) für den Quellpfad.
  • Verwenden Sie die Windows Installer-API, um Quelllisteninformationen für Windows Installer-Anwendungen und -Patches abzurufen und zu ändern. Weitere Informationen finden Sie unter Verwalten von Installationsquellen.
  • Verwenden Sie die Methoden und Eigenschaften des Installer-Objekts, des Produktobjektsund des Patchobjekts, um Quelllisteninformationen für Windows Installer-Anwendungen und -Patches abzurufen und zu ändern.
  • Halten Sie sich an die Punkte, die unter Verhindern, dass ein Patch Zugriff auf die ursprünglichen Installationsquellpunkte erfordert aufgeführt sind, um die Möglichkeit zu minimieren, dass Ihr Patch Zugriff auf die ursprünglichen Quellen benötigt.
  • Store die Paketquelldateien an einem Speicherort ab, der nicht der temporäre Ordner des Systems ist. Windows Im temporären Ordner gespeicherte Installationsquelldateien können für Benutzer nicht mehr verfügbar sein.

Aktivieren Sie bei der Problembehandlung bei der Bereitstellung die ausführliche Protokollierung auf dem Computer des Benutzers.

Windows Installer-Protokollierung enthält eine ausführliche Protokollierungsoption, die auf dem Computer eines Benutzers aktiviert werden kann. Die Informationen in einem ausführlichen Protokoll können bei der Problembehandlung Windows Paketbereitstellung des Installers hilfreich sein.

  • Sie können die ausführliche Protokollierung auf dem Computer des Benutzers aktivieren, indem Sie befehlszeilenoptionen, die MsiLogging-Eigenschaft, die Protokollierungsrichtlinie, MsiEnableLogund die EnableLog-Methode verwenden.
  • Eine sehr nützliche Ressource zum Interpretieren Windows Installer-Protokolldateien ist Wilogutl.exe. Dieses Tool unterstützt die Analyse von Protokolldateien und zeigt vorgeschlagene Lösungen für Fehler an, die in einer Protokolldatei gefunden werden.
  • Weitere Informationen zum Interpretieren Windows Installer-Protokolldateien finden Sie im Whitepaper auf der TechNet-Website: Windows Installer: Vorteile und Implementierung für Systemadministratoren.
  • Die ausführliche Protokollierungsoption sollte nur zu Problembehandlungszwecken verwendet werden und sollte nicht verlassen werden, da sie negative Auswirkungen auf die Systemleistung und den Speicherplatz haben kann. Jedes Mal, wenn Sie das Tool Software hinzufügen/entfernen in Systemsteuerung verwenden, wird eine neue Datei erstellt.

Durch die Deinstallation bleibt der Computer des Benutzers in einem fehlerfreien Zustand.

Das Entfernen von Anwendungen ist genauso wichtig wie die Installation. Wenn ein Windows Installer-Paket deinstalliert wird, sollte es keine unnötigen Teile von sich selbst auf dem Computer des Benutzers zurück lassen.

  • Wenn eine Datei, die vom Computer des Benutzers entfernt werden sollte, nach dem Ausführen einer Deinstallation installiert bleibt, entfernt das Installationsprogramm die Komponente, die die Datei enthält, möglicherweise nicht aus einem oder mehreren der unter Entfernen von hängenden Dateien beschriebenenGründe.
  • Wenn eine Anwendung registriert werden muss, erstellen Sie das Paket, um Registrierungsinformationen zu entfernen, wenn die Anwendung deinstalliert wird. Weitere Informationen finden Sie unter Hinzufügen oder Entfernen von Registrierungsschlüsseln bei der Installation oder Entfernung von Komponenten. Wenn eine Anwendung nicht registriert ist, wird die Anwendung nicht im Feature Software in Systemsteuerung aufgeführt und kann nicht mithilfe des Windows Installers verwaltet werden.
  • Um eine Anwendung in Systemsteuerung aus der Funktion "Programme hinzufügen oder entfernen" auszublenden und trotzdem den Windows Installer zum Verwalten der Anwendung verwenden zu können, befolgen Sie die Unter Hinzufügen und Entfernen einer Anwendung beschriebenen Richtlinien und lassen keine Ablaufverfolgung in der Registrierung.
  • Benutzerdefinierte Aktionen sollten bei der Deinstallation so ausgeführt werden, dass sie nicht wie erforderlich ausgeführt werden. Bei der Installation und Deinstallation müssen möglicherweise verschiedene benutzerdefinierte Aktionen ausgeführt werden.
  • Benutzerspezifische Anpassungsinformationen können in einer Textdatei auf dem Computer gespeichert werden. Dies hat den Vorteil, dass die Datei entfernt werden kann, wenn die Anwendung deinstalliert wird, auch wenn der Benutzer dieser Anpassung derzeit nicht angemeldet ist.

Testen Sie Pakete für die Bereitstellung pro Benutzer und Pro-Computer-Installation.

Es ist eine bewährte Methode, Kunden die Entscheidung zu ermöglichen, ob ein Paket für die Installation entweder im Pro-Computer- oder benutzerbezogenen Installationskontextbereitgestellt werden soll.

  • Überlegen Sie, ob die Anwendung während des Entwicklungsprozesses nur bestimmten Benutzern oder allen Benutzern des Computers zur Verfügung stehen soll.
  • Testen Sie, ob das Paket sowohl für die Installation pro Benutzer als auch für den Installationskontext pro Computer ordnungsgemäß funktioniert.
  • Machen Sie das Paket einfach anpassbar, und lassen Sie Kunden entscheiden, ob es pro Benutzer oder pro Computer bereitgestellt werden soll.

Planen und testen Sie eine Wartungsstrategie, bevor Sie die Anwendung versenden.

Sie sollten entscheiden, wie Sie die Anwendung warten möchten, bevor Sie die Anwendung zum ersten Mal bereitstellen.

  • Berücksichtigen Sie die Arten von Updates, die Sie für die zukünftige Verwendung ihrer Anwendung verwenden werden. Der Windows Installer bietet drei Arten von Updates: Kleines Update, Kleineres Upgradeund Hauptupgrades. Die Unterschiede zwischen diesen werden im Thema Patchen und Upgrades beschrieben.
  • Testen Sie vor dem Versand Ihrer Anwendung, ob sie nach der Wartung mit jedem Updatetyp erwartungsgemäß funktioniert.

Reduzieren Sie die Abhängigkeit von Updates von den ursprünglichen Quellen.

Wenn die ursprünglichen Quelldateien zum Aktualisieren Ihrer Anwendung erforderlich sind, kann dies die Wartung der Anwendung erschweren. Die folgenden Methoden können dazu beitragen, die Abhängigkeit von Updates von den ursprünglichen Quellen zu verringern.

Verteilen Sie keine nicht verwendbaren Mergemodule.

Anwendungen sollten bei der Installation der Komponente nicht von Mergemodulen abhängig sein, wenn sich der Besitzer des Mergemoduls und der Besitzer der Anwendung unterscheiden. Dadurch kann es schwierig sein, die Anwendung zu bedienen, da beide Besitzer die Aktualisierung der Anwendung oder des Moduls koordinieren müssen. Ohne alle Anwendungen zu kennen, die das Mergemodul verwendet haben, kann der Besitzer der Anwendung das Mergemodul nicht aktualisieren, ohne zu riskieren, dass das Update möglicherweise mit einer anderen Anwendung nicht kompatibel ist. Der Besitzer des Mergemoduls verfügt über keine direkte Methode zum Aktualisieren Windows Installer-Pakete, die das Mergemodul bereits installiert haben.

  • Erwägen Sie die Bereitstellung der erforderlichen Komponenten für Benutzer als weitere installation Windows Installer.

Vermeiden Sie das Patchen von Administratorinstallationen.

Stellen Sie in einem Netzwerk eine Administratorinstallation des ursprünglichen Windows Installer-Pakets Ihrer Anwendung bereit, damit Mitglieder einer Arbeitsgruppe die Anwendung installieren können. Benutzer dieses Administratorimages sollten dann Updates auf die lokale Instanz der Anwendung anwenden, die sich auf ihrem Computer befindet. Dies sorgt dafür, dass Benutzer mit dem Administratorimage synchronisiert werden. Das Anwenden von Updates auf die Administratorinstallation wird aus den folgenden Gründen nicht empfohlen.

  • Die Größe und Latenz des Downloads, der für Benutzer erforderlich ist, um ein Update zu erhalten, wird im Vergleich zum Herunterladen eines Patches erhöht. Das gesamte aktualisierte Windows Installer-Paket und die Quelldateien müssen heruntergeladen, neu zwischenspeichert und neu installiert werden.
  • Benutzer können Anwendungen erst nach Bedarf installieren und von einer aktualisierten Administratorinstallation reparieren, wenn sie die Anwendung erneut zwischenspeichern und neu installieren.
  • Durch Anwenden eines Patches auf eine Administratorinstallation wird die digitale Signatur aus dem Paket entfernt. Ein Administrator muss das Paket kündigen. Weitere Informationen zur Verwendung digitaler Signaturen finden Sie unter Digitale Signaturen und Windows Installer.
  • Viele binäre Patches zielen auf das RTM-Image der Anwendung ab und erfordern eine frühere Dateiversion. Die lokale Instanz einer Anwendung, die über eine aktualisierte Administratorinstallation installiert wurde, funktioniert möglicherweise nicht mit anderen Updates. Viele binäre Patchanwendungen können fehlschlagen.
  • Durch anwenden eines Patches auf eine Administratorinstallation werden die Quelldateien und die .msi Datei aktualisiert, aber das Netzwerkimage wird nicht mit Informationen zum Update gestempelt. Benutzer können nicht ermitteln, welche Updates sie von der Administratorinstallation erhalten haben. Dies macht es unmöglich, auf benutzerseitige Updates angewendete Sequenzupdates mit denen zu sequenzen, die bereits auf der Administratorimageseite angewendet wurden.
  • Patches, die auf eine Administratorinstallation angewendet werden, sind keine deinstallationsfähigen Patches. Dadurch kann verhindert werden, dass sich der auf dem Computer des Benutzers zwischengespeicherte Paketcode von dem Paketcode bei der Administratorinstallation unterscheidet. Wenn sich der auf dem Computer des Benutzers zwischengespeicherte Paketcode von dem auf der Administratorinstallation unterscheidet, installieren Sie die Anwendung über die Administratorinstallation neu, und patchen Sie dann den Clientcomputer.
  • Wenn Sie kleine Updates durch Patchen eines administrativen Images anwenden möchten, befolgen Sie die Richtlinien, die im Thema Anwenden kleiner Updates durch Patchen eines administrativen Imagesbeschrieben werden.

Registrieren Sie Updates für die Ausführung mit erhöhten Rechten.

Ab Windows Installer 3.0 ist es möglich, Patches auf eine Anwendung anzuwenden, die in einem benutzerbezogenen verwalteten Kontext installiert wurde, nachdem der Patch als mit erhöhten Rechten registriert wurde. Sie können keine Patches auf Anwendungen anwenden, die in einem benutzerbezogenen verwalteten Kontext mit Versionen von Windows Installer vor Version 3.0 installiert sind.

Verwenden Sie die MsiPatchSequence-Tabelle zum Sequenzen von Patches.

Fügen Sie eine MsiPatchSequence-Tabelle in Ihr Paket ein, und fügen Sie Informationen zur Patchsequenzierung hinzu. Ab Windows Installer Version 3.0 kann das Installationsprogramm die MsiPatchSequence-Tabelle verwenden, wenn mehrere Patches installiert werden, um die beste Patchanwendungssequenz zu ermitteln. Verwenden Sie die Richtlinien, die im Whitepaper Patch sequencing in Windows Installer version 3.0 (Patchsequenzierung in Windows Installer Version 3.0) beschrieben sind, um Patchfamilien zu definieren.

  • Geben Sie ggf. alle Patches als zu einer einzelnen Patchfamilie gehörend an. In vielen Fällen bietet eine einzelne Patchfamilie ausreichend Flexibilität für das Sequenzen von Patches. Die Komplexität der Erstellung steigt, wenn mehrere Patchfamilien verwendet werden. Weisen Sie der Patchfamilie einen aussagekräftigen Namen zu, und weisen Sie Sequenzwerte in dieser Patchfamilie zu, die sich im Laufe der Zeit erhöhen. Befolgen Sie das Beispiel für mehrere Patches, um Patches in der Reihenfolge anzuwenden, in der sie ausgegeben wurden.
  • Verwenden Sie die PatchSequence-Tabelle in Patchwiz.dll, um die Informationen in der MsiPatchSequence-Tabellezu generieren. Die Version von PATCHWIZ.DLL, die mit Windows Installer 3.0 veröffentlicht wurde, kann automatisch Patchsequenzierungsinformationen generieren. Weitere Informationen zum Hinzufügen eines neuen Patches finden Sie unter Generieren von Patchsequenzinformationen. Weitere Informationen zu Patchsequenzierungsszenarien finden Sie im Whitepaper Patch Sequencing in Windows Installer Version 3.0.

Testen Sie das Installationspaket gründlich.

Testen Sie, ob das Windows Installer-Paket ordnungsgemäß installiert, repariert und entfernt wurde. Sie können den Testprozess in die folgenden Teile unterteilen.

  • Installationstests: Testen Sie die Installation mit allen möglichen Kombinationen von Anwendungsfeatures. Testen Sie alle Installationstypen, einschließlich Administrative Installation, Rollbackinstallationund Installation-On-Demand. Probieren Sie alle möglichen Installationsmethoden aus, z. B. das Klicken auf die .msi-Datei, Befehlszeilenoptionenund die Installation über die Systemsteuerung. Testen Sie, ob das Paket von Benutzern in allen möglichen Berechtigungskontexten installiert werden kann. Versuchen Sie, das Paket zu installieren, nachdem es mit allen möglichen Methoden bereitgestellt wurde. Aktivieren Sie Windows Installer-Protokollierung für jeden Test, und beheben Sie alle Fehler, die im Installationsprogramm- und Ereignisprotokoll gefunden wurden.
  • Benutzeroberfläche Testing: Testen Sie das Paket, wenn es mit allen möglichen Benutzeroberflächenebeneninstalliert ist. Testen Sie das installierte Paket ohne Benutzeroberfläche und mit allen Informationen, die über die Benutzeroberfläche bereitgestellt werden. Stellen Sie sicher, dass die Barrierefreiheit der Benutzeroberfläche und die Benutzeroberfläche für unterschiedliche Bildschirmauflösungen und Schriftgrade erwartungsgemäß funktionieren.
  • Wartungs- und Reparaturtests: Testen Sie, ob das Paket Patches und Upgrades verarbeiten kann, die durch ein kleines Update, ein kleineres Upgradeund größere Upgradesbereitgestellt werden. Schreiben Sie vor der Bereitstellung des Pakets ein Testupdate für jeden Typ, und versuchen Sie, es auf das ursprüngliche Paket anzuwenden.
  • Deinstallieren von Tests: Stellen Sie sicher, dass beim Entfernen des Pakets keine unnötigen Teile von sich selbst auf dem Computer des Benutzers zurückbleiben und dass nur informationen entfernt wurden, die zum Paket gehören. Starten Sie den Testcomputer nach der Deinstallation des Pakets neu, und überprüfen Sie die Integrität gängiger Systemtools und anderer Standardanwendungen. Testen Sie, ob das Paket von Benutzern in allen möglichen Berechtigungskontexten entfernt werden kann. Testen Sie alle Methoden, um das Paket zu entfernen, klicken Sie auf die datei .msi, testen Sie die Befehlszeilenoptionen,und entfernen Sie das Paket aus der Systemsteuerung. Aktivieren Sie Windows Installer-Protokollierung für jeden Test, und beheben Sie alle Fehler, die im Installationsprogramm- und Ereignisprotokoll gefunden wurden.
  • Testen der Produktfunktionalität: Stellen Sie sicher, dass die Anwendung nach der Installation, Reparatur oder Entfernung des Pakets wie erwartet funktioniert.

Beheben Sie alle Validierungsfehler, bevor Sie ein neues oder überarbeitetes Installationspaket bereitstellen.

Führen Sie die Paketvalidierung für ein neues oder überarbeitetes Windows Installer-Paket aus, bevor Sie versuchen, es zum ersten Mal zu installieren. Bei der Überprüfung wird die Windows Installer-Datenbank auf Erstellungsfehler überprüft. Der Versuch, ein Paket zu installieren, das die Überprüfung nicht bestanden hat, kann das System des Benutzers beschädigen.

  • Sie können Ihr Paket mit Orca.exe oder Msival2.exeüberprüfen. Beide Tools werden mit dem Windows SDK bereitgestellt. Drittanbieter können auch das ICE-Überprüfungssystem in ihre Erstellungsumgebung integrieren.
  • Sie können den Standardsatz interner Konsistenzauswertungen verwenden– ICEs, die in den CUB-Dateien enthalten sind, die mit dem SDK bereitgestellt werden. Alternativ können Sie die Überprüfung anpassen, indem Sie einen ICE erstellen und der CUB-Datei hinzufügen.
  • Sie können die Evalcom2.dll verwenden, um Validation Automation für Installationspakete und Mergemodule zu implementieren.

Erstellen sie eine sichere Installation.

Befolgen Sie diese Richtlinien bei der Entwicklung Ihres Pakets, um eine sichere Umgebung während der Installation beizubehalten.

Verwenden von PMSIHANDLE anstelle von HANDLE

Die PMSIHANDLE-Typvariablen werden in msi.h definiert. Es wird empfohlen, dass Ihre Anwendung den PMSIHANDLE-Typ verwendet, da das Installationsprogramm PMSIHANDLE-Objekte schließt, sobald sie den Gültigkeitsbereich sprengen, während Ihre Anwendung MSIHANDLE-Objekte durch Aufrufen von MsiCloseHandleschließen muss.

Wenn Sie z. B. Code wie den folgenden verwenden:

MSIHANDLE hRec = MsiCreateRecord(3);

Ändern Sie sie in:

PMSIHANDLE hRec = MsiCreateRecord(3);