Erstellen einzelner Pakete
Ein Dual-Purpose-Paket ist ein Windows Installer 5.0-Paket, das so erstellt wurde, dass es eine Anwendung entweder im Benutzer- oder pro Computerinstallationskontextinstallieren kann. Setupentwickler, die ein Dual-Purpose-Paket für ihre Anwendung verwenden, können ihren Benutzern zur Installationszeit eine Auswahl des Installationskontexts bereitstellen und Eingabeaufforderungen für UAC-Anmeldeinformationen aus Benutzerinstallationen auf Windows 7 oder Windows Server 2008 R2 entfernen. Die Entwicklung eines Dual-Purpose Windows Installer 5.0-Pakets für die Installation auf Windows 7 und Windows Server 2008 R2 wird als Erstellung einzelner Pakete bezeichnet.
Sie können mit der Entwicklung von Dual-Purpose-Paketen für Windows 7 und Windows Server 2008 R2 beginnen, indem Sie Windows Installer 5.0, die MSIINSTALLPERUSER-Eigenschaft, die ALLUSERS-Eigenschaft und die benutzerfähigen bekannten Ordner und Registrierungen der Windows Shellverwenden. Wenn Windows Installer 5.0 ein Dual-Purpose-Paket im Benutzerkontext auf Windows 7 oder Windows Server 2008 R2 installiert, leitet das Installationsprogramm Datei- und Registrierungseinträge an benutzerspezifische Speicherorte weiter und zeigt keine UAC-Eingabeaufforderungen für Anmeldeinformationen an. Wenn Windows Installer 5.0 ein Dual-Purpose-Paket im Kontext pro Computer installiert, leitet das Installationsprogramm Dateien und Registrierungseinträge an computerspezifische Speicherorte weiter und fordert zur Eingabe von UAC-Anmeldeinformationen auf, um zu bestätigen, dass der Benutzer über ausreichende Berechtigungen zum Installieren von Software für alle Benutzer des Computers verfügt. Sobald Windows Installer 5.0 eine Anwendung installiert, wird für alle nachfolgenden Updates, Reparaturen oder Entfernungen der Anwendung derselbe Installationskontext verwendet.
Windows Installer 4.5 oder früher: Die MSIINSTALLPERUSER-Eigenschaft und die Benutzerversionen von Ordnern, auf die von den Eigenschaften ProgramFilesFolder, CommonFilesFolder, ProgramFiles64Folderund CommonFiles64Folder verwiesen wird, werden nicht unterstützt. Die Ordner FOLDERID _ UserProgramFiles und FOLDERID _ UserProgramFilesCommon sind ab Windows 7 und Windows Server 2008 R2 verfügbar. Dies bedeutet, dass Installationen, die für Windows Installer 4.5 oder früher entwickelt wurden, Dateien und Registrierungseinträge direkt an FOLDERID _ ProgramFiles, FOLDERID _ ProgramFilesCommon, FOLDERID _ ProgramFilesX64 und FOLDERID _ ProgramFilesCommonX64 leiten. Da es sich hierbei um Speicherorte handelt, auf die andere Benutzer des Computers zugreifen können, erfordern Windows Vista- und spätere Systeme die Anzeige von UAC-Eingabeaufforderungen für Anmeldeinformationen.
Wenn ein Benutzer ein Dual-Purpose-Paket installiert, das für Windows Installer 5.0 mit Windows Installer 4.5 oder früher erstellt wurde, ignoriert das Installationsprogramm die MSIINSTALLPERUSER-Eigenschaft. In diesem Fall kann die Installation Dateien und Registrierungseinträge an Speicherorte leiten, auf die andere Benutzer zugreifen können, und das System muss UAC-Eingabeaufforderungen für Anmeldeinformationen anzeigen. Windows Installer 5.0 kann ein Paket installieren, das für Windows Installer 4.5 oder früher entwickelt wurde. Die Installation leitet jedoch Dateien und Registrierungseinträge an Speicherorte weiter, auf die andere Benutzer zugreifen können, und erfordert, dass das System UAC-Eingabeaufforderungen für Anmeldeinformationen anzeigt.
Entwicklungsrichtlinien
Befolgen Sie die folgenden Richtlinien für die Erstellung einzelner Pakete, um sicherzustellen, dass das Paket im Kontext pro Benutzer oder pro Computer installiert werden kann. Befolgen Sie diese Richtlinien, um es dem Benutzer zu ermöglichen, zur Installationszeit eine Installation pro Benutzer oder pro Computer auszuwählen und UAC-Eingabeaufforderungen aus benutzerbezogenen Installationen zu entfernen.
Für die Installation pro Benutzer ist Windows Installer 5.0 auf Windows 7 oder Windows Server 2008 R2 erforderlich. Sie sollten den Benutzer darüber informieren, dass das Paket die computerspezifische Installation der Anwendung in früheren Versionen des Systems unterstützt.
Initialisieren Sie die Werte für die Eigenschaften ALLUSERS und MSIINSTALLPERUSER in der Eigenschaftentabelle Ihres Dual-Purpose-Pakets. Verwenden Sie den ALLUSERS-Wert 2 und den MSIINSTALLPERUSER-Wert 1 als Anfangswerte. Dies gibt die Installation pro Benutzer als Standard für das Dual-Purpose-Paket an.
Erwägen Sie die Erstellung eines Dialogfelds für die Benutzeroberfläche Ihres Dual-Purpose-Pakets, das es dem Benutzer ermöglicht, den Kontext zur Installationszeit auszuwählen. Erstellen Sie die Steuerelemente in diesem benutzerdefinierten Dialogfeld, um die Werte der Eigenschaften ALLUSERS und MSIINSTALLPERUSER festzulegen. Legen Sie für den ALLUSERS-Wert 2 MSIINSTALLPERUSER auf den Wert 1 fest, um eine benutzerspezifische Installation anzugeben, und legen Sie MSIINSTALLPERUSER auf eine leere Zeichenfolge ("") fest, um eine Installation pro Computer anzugeben. Benutzer können allusers und MSIINSTALLPERUSER auch in der Befehlszeile festlegen, wenn sie das Paket über die Befehlszeile installieren.
Überprüfen Sie das Paket mithilfe interner Konsistenzauswertungen– ICEs . Das Paket muss die Überprüfung durch ICE105 bestehen können, um ein gültiges Dual-Purpose-Paket zu sein.
Verwenden Sie die Registrierungstabelle und die RemoveRegistry-Tabelle, um Registrierungseinträge während benutzerbasierter Installationen an die Benutzerteile der Registrierung umzuleiten. Bei einer Installation pro Benutzer werden Registrierungseinträge mit -1 in der Stammspalte an HKEY _ CURRENT _ USER umgeleitet, und in einer Computerinstallation werden diese an HKEY _ LOCAL _ MACHINE weitergeleitet. Bei einer Installation pro Benutzer werden Registrierungseinträge mit msidbRegistryRootClassesRoot (0) in der Stammspalte an HKCU-Softwareklassen umgeleitet, \ \ und in einer Computerinstallation werden diese an HKLM-Softwareklassen \ \ weitergeleitet.
Verwenden Sie die ProgramFilesFolder-Eigenschaft in der Directory-Tabelle von 32-Bit-Windows Installer-Paketen, um die Speicherorte von Verzeichnissen anzugeben, die 32-Bit-Komponenten enthalten, die nicht anwendungsübergreifend freigegeben sind. Wenn ein Benutzer das Dual-Purpose-Paket mithilfe des Kontexts pro Computer installiert, werden diese Komponenten im Ordner Programme auf 32-Bit-Versionen von Windows und im Ordner Programme (x86) auf 64-Bit-Versionen des Systems gespeichert. Alle Benutzer können auf die Komponenten in diesen Verzeichnissen zugreifen. Wenn ein Benutzer das Dual-Purpose-Paket mithilfe des Benutzerkontexts auf Windows 7 oder Windows Server 2008 R2 installiert, werden diese Komponenten im Ordner Programme des aktuellen Benutzers gespeichert (z. B. unter %LocalAppData%-Programme), auf die \ nur dieser Benutzer zugreifen kann.
Verwenden Sie die CommonFilesFolder-Eigenschaft in der Directory-Tabelle von 32-Bit-Windows Installer-Paketen, um die Speicherorte von Verzeichnissen anzugeben, die anwendungsübergreifende 32-Bit-Komponenten enthalten. Wenn ein Benutzer das Dual-Purpose-Paket mithilfe des Kontexts pro Computer installiert, werden diese Komponenten im Ordner Allgemeine Dateien gespeichert und können von allen Benutzern aufgerufen werden. Wenn ein Benutzer das Dual-Purpose-Paket mithilfe des Benutzerkontexts auf Windows 7 oder Windows Server 2008 R2 installiert, werden diese Komponenten im Ordner Common des aktuellen Benutzers gespeichert (z. B. unter %LocalAppData% Programs Common) und können nur von diesem \ Benutzer aufgerufen \ werden.
Verwenden Sie die ProgramFiles64Folder-Eigenschaft in der Verzeichnistabelle von 64-Bit-Windows Installer-Paketen, um die Speicherorte von Verzeichnissen anzugeben, die 64-Bit-Komponenten enthalten, die nicht anwendungsübergreifend freigegeben sind. Wenn ein Benutzer das Dual-Purpose-Paket mithilfe des Kontexts pro Computer installiert, werden diese Komponenten im Ordner Programme gespeichert. Alle Benutzer können auf die Komponenten in diesen Verzeichnissen zugreifen. Wenn ein Benutzer das Dual-Purpose-Paket mithilfe des Benutzerkontexts auf Windows 7 oder Windows Server 2008 R2 installiert, werden diese Komponenten im Ordner Programme des aktuellen Benutzers gespeichert (z. B. unter %LocalAppData%-Programme), auf die \ nur dieser Benutzer zugreifen kann. Weitere Informationen zum Erstellen eines Pakets zum Installieren einer Anwendung unter 64-Bit-Betriebssystemen finden Sie unter Windows Installer unter 64-Bit-Betriebssystemen.
Verwenden Sie die CommonFiles64Folder-Eigenschaft in der Directory-Tabelle von 64-Bit-Windows Installer-Paketen, um die Speicherorte von Verzeichnissen anzugeben, die 64-Bit-Komponenten enthalten, die anwendungsübergreifend freigegeben sind. Wenn ein Benutzer das Dual-Purpose-Paket mithilfe des Kontexts pro Computer installiert, werden diese Komponenten im Ordner Allgemeine Dateien gespeichert und können von allen Benutzern aufgerufen werden. Wenn ein Benutzer das Dual-Purpose-Paket mithilfe des Benutzerkontexts auf Windows 7 oder Windows Server 2008 R2 installiert, werden diese Komponenten im Ordner Common des aktuellen Benutzers gespeichert (z. B. unter %LocalAppData% Programs Common) und können nur von diesem \ Benutzer aufgerufen \ werden.
Verwenden Sie die Eigenschaften ProgramFilesFolder und CommonFilesFolder in der Verzeichnistabelle von 64-Bit-Windows Installer-Paketen, um den Speicherort von Verzeichnissen anzugeben, die 32-Bit-Komponenten enthalten. Verwenden Sie unterschiedliche Namen für die 32-Bit- und 64-Bit-Versionen aller Komponenten, die mit dem gleichen Namen bereitgestellt werden, oder speichern Sie die Versionen alternativ in verschiedenen Ordnern. Fügen Sie der Directory-Tabelle beispielsweise Informationen hinzu, um den Speicherort des Verzeichnisses mit der 32-Bit-Version als [ ProgramFilesFolder ] \ ISV Name \ Application Name \ x86 und den Speicherort des Verzeichnisses mit der 64-Bit-Version als [ Program64FilesFolder ] \ ISV Name Application Name Application \ Name \ anzugeben. Bei einer Installation pro Computer wird dann die 32-Bit-Version in Program Files(x86) \ ISV Name \ Application Name \ x86 gespeichert, und die 64-Bit-Version wird in Program Files \ ISV Name Application Name Application \ Name \ x64 gespeichert. Bei einer Benutzerinstallation wird die 32-Bit-Version in %LocalAppData% \ Programs \ ISV Name \ Application Name x86 gespeichert und die \ 64-Bit-Version in %LocalAppData% \ Programs \ ISV Name Application \ Name \ x64 installiert.
Store benutzerspezifische Konfigurationsdaten für die Anwendung unter \ \ Benutzerbenutzername \ AppData.
Store Vorlagen und Dateien, die von der Anwendung in Unterordnern unter \ \ Benutzerbenutzername generiert werden.
Wenn Ihre Anwendung Shellerweiterungen verwendet, sollten Sie die benutzerfähigen Shellerweiterungspunkte verwenden, die ab Windows 7 oder Windows Server 2008 R2 verfügbar sind.
Verwenden Sie keine benutzerdefinierten Aktionen in Ihrem Paket, für deren Ausführung erhöhte Rechte erforderlich sind. Die Tabelle CustomAction sollte keine benutzerdefinierten Aktionen enthalten, die für die Ausführung mit erhöhten Rechten markiert wurden. Weitere Informationen zu benutzerdefinierten Aktionen mit erhöhten Rechten finden Sie unter Benutzerdefinierte Aktionssicherheit.
Schreiben Sie nicht in globale Systemordner. Die Directory-Tabelle darf keinen Verweis auf die folgenden Systemordnereigenschaften enthalten.
AdminToolsFolder
CommonAppDataFolder
SchriftartenOrdner
System16Folder
System64Folder
SystemFolder
TempFolder
WindowsFolder
WindowsVolume
- Installieren Sie keine Common Language Runtime-Assembly im globalen Assemblycache (GAC). Weitere Informationen zum Installieren von Assemblys im globalen Assemblycache finden Sie unter Hinzufügen von Assemblys zu einem Paket und Installation von Common Language Runtime-Assemblys.
- Installieren Sie keine ODBC-Datenquellen. Verwenden Sie die ODBCDataSource-Tabelle nicht, um eine Datenquelle zu installieren.
- Installieren Sie keine Dienste. Verwenden Sie nicht die Tabelle ServiceInstall, um einen Dienst zu installieren.
Beispiel
Ein Beispiel für ein Dual-Purpose-Paket finden Sie in den Windows SDK-Komponenten für Windows Installer-Entwickler als Datei PUASample1.msi. Wenn Sie über das aktuelle SDK verfügen, haben Sie Zugriff auf alle Tools und Daten, die zum Reproduzieren des Beispielinstallationspakets erforderlich sind. Weitere Informationen zu diesem Beispiel finden Sie unter Single Package Authoring Example.