Ich versuche, den Unterschied zwischen GUID- und Nicht-GUID-Schlüsseln in HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall zu verstehen.
Manche Dinge haben einen GUID-Schlüssel und einen Nicht-GUID-Schlüssel mit sehr unterschiedlichen UninstallStrings. Autodesk Revit hat beispielsweise einen guten UninstallString im GUID-Schlüssel
MsiExec.exe /X{7346B4A0-1900-0510-0000-705C0D862004})
Aber im Nicht-GUID-Schlüssel ist der UninstallString meiner Meinung nach tatsächlich ein Patch-String.
C:\Program Files\Autodesk\Revit 2019\Setup\Setup.exe /P {7346B4A0-1900-0510-0000-705C0D862004} /M RVT /LANG en-US)
Andere, beispielsweise die Autodesk Desktop App, verfügen jedoch nicht über einen GUID-Schlüssel, und der UninstallString im Nicht-GUID-Schlüssel ist gut.
C:\Program Files (x86)\Autodesk\Autodesk Desktop App\removeAdAppMgr.exe
Ich frage mich, ob das normal ist oder vielleicht etwas Verrücktes, das nur Autodesk macht. Und gibt es eine gute Microsoft-Ressource, in der detailliert beschrieben wird, welche Informationen in den verschiedenen Deinstallationsordnern erwartet werden? Bisher konnte ich nichts Genaueres finden.
EDIT: In ähnlicher Weise stelle ich fest, dass Microsoft auch Duplikate erstellt, aber nicht GUID vs. nicht. Hier sind drei verschiedene Deinstallationen mit demselben DisplayName, aber drei verschiedenen referenzierten GUIDs. Außerdem sind dies alles x64-Installationen, die aber in WOW6432Node gefunden werden. Frustrierend.
Visual C++ 2008 - x64 (KB958357) - v9.0.30729.177
C:\Windows\SysWOW64\msiexec.exe /x {8CCEA24C-51AE-3B71-9092-7D0C44DDA2DF} /qb+ REBOOTPROMPT=""
Visual C++ 2008 - x64 (KB958357) - v9.0.30729.177
C:\Windows\SysWOW64\msiexec.exe /x {C3A57BB3-9AA6-3F6F-9395-6C062BDD5FC4} /qb+ REBOOTPROMPT=""
Visual C++ 2008 - x64 (KB958357) - v9.0.30729.177
C:\Windows\SysWOW64\msiexec.exe /x {F6F09DD8-F39B-3A16-ADB9-C9E6B56903F9} /qb+ REBOOTPROMPT=""
Antwort1
Gute Antwort, bereits gepostet. Ich werde trotzdem posten, was ich zu schreiben begonnen habe, bevor Ihre Frage zuvor gelöscht wurde.
DerGUID
Schlüssel sind im AllgemeinenWindows Installer setups
(Dateien mit*.MSI
Erweiterung) – der veraltete Standard für die intensive Nutzung von Microsoft in Unternehmen.
Es gibt viele unterschiedliche Arten von Installationsprogrammen, sie sind jedoch im Allgemeinen als setup.exe
Dateien oder MSI files
in neueren Installationsformaten wie APPX
(bereits veraltet), MSIX
(aufstrebend) usw. verpackt. Es gibt wirklich viele Möglichkeiten.
Autodeskscheint ein setup.ex
E-Installer-Programm im Legacy-Stil zu verwenden, das nicht auf basiert Windows Installer
, obwohl es immer noch möglich ist, dass das setup.exe
, auf das verwiesen wird, ein Wrapper ist, der ein Windows Installer-Paket startet.
Ich werde unten einige Links mit Informationen zu verschiedenen Setup-Typen und den mit dem Umgang mit Setups verbundenen Aufgaben (wie etwa der Dateiextraktion) hinzufügen.
Einige Links:
- MSI aus EXE extrahieren(viele weiterführende Links)
- Einfache Listenansicht der am häufigsten verwendeten Bereitstellungstools(für Windows Installer)
- Ausführlichere Linkliste mit Bereitstellungstools(aller Art)
- Wie finde ich die Produkt-GUID eines installierten MSI-Setups?
- Deinstallieren einer MSI-Datei über die Befehlszeile ohne Verwendung von msiexec
In diesen Antworten sind zahlreiche weitere Links zu ähnlichen Themen eingebettet.
Antwort2
Wenn ein Entwickler eine Anwendung erstellt, wählt er normalerweise eine Methode zur Installation. Eine beliebte Option ist die Verwendung von Windows Installer und damit die Erstellung einer MSI. Eine MSI-Datei ist im Wesentlichen eine Datenbank, die Windows Installer mitteilt, wie die Software installiert werden soll, d. h. welche Dateien abgelegt, welche Registrierungsschlüssel erstellt, welche Dienste erstellt werden sollen usw. Beliebte Tools zum Erstellen von MSI-Dateien sindWiXoderInstallShield.
Beim Erstellen einer MSI sollte dem Produkt eine eindeutige GUID namens ProductCode zugewiesen werden. Diesen Produktcode sehen Sie unter dem Schlüssel Uninstall. Der Wert UninstallString verwendet den ProductCode, da Windows Installer diesen verwenden kann, um die Anwendung mit dem Schalter /X zu deinstallieren.
Der Entwickler kann sich dafür entscheiden, Windows Installer nicht zu verwenden und sein eigenes Installationsprogramm zu schreiben. Damit es jedoch in Programme und Funktionen angezeigt wird, muss der Entwickler die Deinstallationsschlüssel für die Anwendung manuell erstellen. Zumindest müssten sie DisplayName und UninstallString festlegen (Referenz). Es ist unwahrscheinlich, dass sie eine GUID zur Identifizierung der Anwendung erstellen würden, aber sie könnten.
Wenn der Entwickler ein benutzerdefiniertes Installationsprogramm erstellt hat, muss er auch eine Methode zum Deinstallieren der Anwendung bereitstellen. Daher erstellen die meisten Entwickler eine separate Deinstallationsanwendung, auf die von UninstallString verwiesen wird. Diese Anwendung könnte auch verwendet werden, um eine Option zum Ändern, Reparieren oder Deinstallieren der Anwendung bereitzustellen.
Es ist wirklich die Präferenz des Entwicklers.