Estoy tratando de comprender la diferencia entre claves GUID y no GUID en HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall.
Algunas cosas tienen una clave GUID y una clave no GUID, con UninstallStrings muy diferentes. Por ejemplo, Autodesk Revit tiene un buen UninstallString en la clave GUID
MsiExec.exe /X{7346B4A0-1900-0510-0000-705C0D862004})
Pero creo que en la clave que no es GUID, UninstallString es en realidad una cadena de parche.
C:\Program Files\Autodesk\Revit 2019\Setup\Setup.exe /P {7346B4A0-1900-0510-0000-705C0D862004} /M RVT /LANG en-US)
Pero otros, como la aplicación de escritorio de Autodesk, no tienen una clave GUID y el UninstallString en la clave que no es GUID es bueno.
C:\Program Files (x86)\Autodesk\Autodesk Desktop App\removeAdAppMgr.exe
Me pregunto: ¿es esto normal o tal vez algo ridículo que sólo hace Autodesk? Y, ¿existe algún buen recurso de Microsoft que detalla qué información se espera en las distintas carpetas de desinstalación? Hasta ahora no puedo encontrar nada detallado.
EDITAR: En una nota similar, encuentro que Microsoft también hace duplicados, pero no GUID o no. Aquí hay tres desinstalaciones diferentes con el mismo DisplayName, pero con tres GUID diferentes referenciados. Además, todas estas son instalaciones x64, pero se encuentran en WOW6432Node. Frustrante.
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=""
Respuesta1
Buena respuesta ya publicada. Seguiré publicando lo que comencé a escribir antes de que se borrara tu pregunta antes.
ElGUIDLas claves son generalmenteWindows Installer setups(archivos con*.MSIextensión): el estándar antiguo para la implementación de Microsoft de uso intensivo en corporaciones.
Hay muchos tipos diferentes de instaladores, pero generalmente están empaquetados como setup.exearchivos o MSI filestipos más nuevos de formatos de instalador como APPX(ya obsoleto), MSIX(emergente), etc... Realmente hay muchas posibilidades.
AutoDeskParece estar usando un setup.exinstalador de estilo heredado que no está basado en Windows Installer, aunque todavía es posible que el setup.exeque se señala sea un contenedor que inicia un paquete de Windows Installer.
Agregaré algunos enlaces a continuación para obtener información sobre varios tipos de configuraciones y tareas involucradas al tratar con configuraciones (como la extracción de archivos).
Algunos enlaces:
- Extraer MSI de EXE(muchos enlaces adicionales)
- Vista de lista simple de las herramientas de implementación más utilizadas(para instalador de Windows)
- Lista de enlaces más completa de herramientas de implementación(De todo tipo)
- ¿Cómo puedo encontrar el GUID del producto de una configuración MSI instalada?
- Desinstalar un archivo MSI desde la línea de comando sin usar msiexec
Hay muchos otros enlaces integrados en estas respuestas a cosas similares.
Respuesta2
Cuando un desarrollador crea una aplicación, normalmente elige un método para instalarla. Una opción popular es utilizar Windows Installer y, por tanto, crear un MSI. Un archivo MSI es esencialmente una base de datos que le indica a Windows Installer cómo instalar el software, es decir, archivos que eliminar, claves de registro que crear, servicios que crear, etc. Las herramientas populares para crear archivos MSI sonWiXoInstalar escudo.
Como parte de la creación de un MSI, al producto se le debe asignar un GUID único llamado ProductCode. Es este código de producto el que ve debajo de la clave Desinstalar. El valor UninstallString usa ProductCode ya que Windows Installer puede usarlo para desinstalar la aplicación usando el modificador /X.
El desarrollador puede optar por no utilizar Windows Installer y escribir su propio instalador. Sin embargo, para que aparezca en Programas y características, el desarrollador deberá crear manualmente las claves de desinstalación de la aplicación. Como mínimo, necesitarían configurar DisplayName y UninstallString (árbitro). Es poco probable que creen un GUID para identificar la aplicación, pero podrían hacerlo.
Si el desarrollador creó un instalador personalizado, entonces también debe proporcionar algún método para desinstalar la aplicación. Como resultado, la mayoría de los desarrolladores crean una aplicación de desinstalación independiente, a la que se accede desde UninstallString. Esta aplicación también podría usarse para presentar una opción para modificar, reparar o desinstalar la aplicación.
Realmente es la preferencia del desarrollador.