Installer benutzerdefinierte Aktion kann nicht alle Registrierungswerte lesen

Question

Verwenden von Visual Studio 2015. Ich versuche, eine benutzerdefinierte Installation des Installationsprogramms zu erstellen, die ein Excel-Add-In bei der Deinstallation "abmeldet". Im Wesentlichen muss es durch die Schlüssel in HKCU\Software\Microsoft\Office suchen und irgendeinen Unterschlüssel finden, der eine Versionsnummer ist (16.0 zB), dann in den Unterschlüssel Excel\Options schauen (wenn es existiert) und nach dem Add-In-Namen in einem der OPEN Werte suchen (Excel führt Add-Ins in der Registrierung unter Verwendung von OPEN, OPEN1, OPEN2 usw. auf.

Beim Debuggen meiner benutzerdefinierten Aktion sieht es so aus, als könnten nicht alle Registrierungswerte angezeigt werden. Als ein Beispiel berichtet es, dass es 8 Unterschlüssel unter HKCU\Software\Microsoft\Office gibt, wenn es tatsächlich 10 Unterschlüssel gibt. Ich vermute, dass dies aufgrund ist Virtualisierung in der Registrierung so dass ich versucht habe, die Anwendung zu erzwingen, wie unten eine bestimmte Registrierungsansicht zu öffnen:

x64: RegistryKey.OpenBaseKey(RegistryHive.CurrentUser, RegistryView.Registry64)

x86: RegistryKey.OpenBaseKey(RegistryHive.CurrentUser, RegistryView.Registry32)

Verwendung entweder von Diese Aufrufe führen zu genau derselben eingeschränkten Registrierungsansicht (ich sehe immer noch 8 Schlüssel statt 10). Es scheint also, dass die benutzerdefinierte Installationssitzung eine bestimmte Registrierungsansicht aus irgendeinem Grund nicht erzwingen kann.

Ich habe eine Konsolenanwendung erstellt, um einige zusätzliche Tests durchzuführen, und die Konsolenanwendung kann die vollen 10 Schlüssel anzeigen, unabhängig davon, ob sie auf x64- oder x86-Plattformen kompiliert wurde.

Ich bin hier etwas ratlos. Ist dies ein bekanntes Problem bei VS2015-Setup-Projekten? Sind sie in ihrer Fähigkeit eingeschränkt, bestimmte Teile der Registrierung anzuzeigen? Oder ist es nur ein Codefehler von meiner Seite?

Hier ist der Code, den ich versuche, die Registrierung zu entfernen, wenn es hilft. Ich habe auf dem Weg eine Menge Fehler hinzugefügt, da es zu fatalen Fehlern bei der Deinstallation kam. Die Deinstallation funktioniert jetzt (sofern dies nicht zu einem Absturz führt), hebt jedoch die Registrierung des Add-Ins nicht wirklich auf, da sie anscheinend nicht die vollständige Registrierung sehen kann.

If Registry.CurrentUser.OpenSubKey("Software\Microsoft\Office", True) IsNot Nothing Then 
    Dim regCUOffice As RegistryKey = Registry.CurrentUser.OpenSubKey("Software\Microsoft\Office", True) 
    If regCUOffice.GetSubKeyNames.Count > 0 Then 
     For Each strKeyName As String In regCUOffice.GetSubKeyNames 
      If regCUOffice.OpenSubKey(strKeyName & "\Excel\Options", True) IsNot Nothing Then 
       Dim regExcelOptionsKey As RegistryKey = regCUOffice.OpenSubKey(strKeyName, True).OpenSubKey("Excel\Options", True) 
       For Each strValueName As String In regExcelOptionsKey.GetValueNames 
        If strValueName IsNot Nothing Then 
         If (strValueName.Equals("OPEN") Or strValueName.StartsWith("OPEN")) Then 
          If regExcelOptionsKey.GetValue(strValueName) IsNot Nothing Then 
           If regExcelOptionsKey.GetValue(strValueName).Equals("MyAddIn.xll") Then 
            regExcelOptionsKey.DeleteValue(strValueName) 
           End If 
          End If 
         End If 
        End If 
       Next 
       regExcelOptionsKey.Close() 
      End If 
     Next 
    End If 
    regCUOffice.Close() 
End If 

Answer 1

Nach einer Tonne Forschung und Arbeit an diesem, glaube ich, dass ich das Problem herausgefunden.

Anscheinend werden benutzerdefinierte Aktionen, die in einem Setup-Projekt in Visual Studio erstellt werden, als ein generisches SYSTEM-Konto ausgeführt. Die HKCU-Registrierungsstruktur ist also die des Systemkontos und nicht der aktuell angemeldete Benutzer. Es ist jedoch möglich, dieses Verhalten zu umgehen.

Die praktikabelste Lösung, die ich fand, besteht darin, das Identitätswechsel-Flag im MSI umzudrehen, nachdem es erstellt wurde. Dadurch können benutzerdefinierte Aktionen installiert werden, um die Identität des derzeit angemeldeten Benutzers anzunehmen. Leider ist das Umklappen dieser Flagge nicht besonders intuitiv. Ich kam schließlich auf dieses Skript, welches für Sie die ganze Lauferei tut:

// CustomAction_Impersonate.js <msi-file> 
// Performs a post-build fixup of an msi to change all deferred custom actions to Impersonate 
// Constant values from Windows Installer 
var msiOpenDatabaseModeTransact = 1; 

var msiViewModifyInsert   = 1 
var msiViewModifyUpdate   = 2 
var msiViewModifyAssign   = 3 
var msiViewModifyReplace  = 4 
var msiViewModifyDelete   = 6 

var msidbCustomActionTypeInScript  = 0x00000400; 
var msidbCustomActionTypeNoImpersonate = 0x00000800 

if (WScript.Arguments.Length != 1) 
{ 
     WScript.StdErr.WriteLine(WScript.ScriptName + " file"); 
     WScript.Quit(1); 
} 

var filespec = WScript.Arguments(0); 
var installer = WScript.CreateObject("WindowsInstaller.Installer"); 
var database = installer.OpenDatabase(filespec, msiOpenDatabaseModeTransact); 

var sql 
var view 
var record 

try 
{ 
     sql = "SELECT `Action`, `Type`, `Source`, `Target` FROM `CustomAction`"; 
     view = database.OpenView(sql); 
     view.Execute(); 
     record = view.Fetch(); 
    //Loop through all the Custom Actions 
     while (record) 
     { 
      if (record.IntegerData(2) & msidbCustomActionTypeInScript) 
      { 
       //We must flip the msidbCustomActionTypeNoImpersonate bit only for deferred custom actions 
       record.IntegerData(2) = record.IntegerData(2) & ~msidbCustomActionTypeNoImpersonate; 
       view.Modify(msiViewModifyReplace, record); 
      } 
     record = view.Fetch(); 
     } 

     view.Close(); 
     database.Commit(); 
} 
catch(e) 
{ 
     WScript.StdErr.WriteLine(e); 
     WScript.Quit(1); 
} 

Speichern dieses Skript als CustomAction_Impersonate.js im Projektordner für die Setup-Projekt (das heißt, wo Ihre SetupProjectName.vdproj Datei befindet). Wählen Sie dann in Visual Studio Ihr Setup-Projekt und öffnen Sie das Eigenschaftenfenster. Fügen Sie in der PostBuildEvent-Eigenschaft cscript.exe "$(ProjectDir)CustomAction_Impersonate.js" "$(BuiltOuputPath)" hinzu.

Im Wesentlichen weist diese Zeile Visual Studio an, Ihr Projekt zu erstellen und nach dem erfolgreichen Erstellen das von Ihnen gespeicherte Skript auszuführen.Das Skript dreht das Identitätswechsel-Flag um, damit die benutzerdefinierte Installation des Installationsprogramms als angemeldeter Benutzer ausgeführt werden kann.

In meinen ersten Tests scheint dies den Trick zu tun. Ich werde hier aktualisieren, wenn ich finde, dass diese Lösung aus irgendeinem Grund nicht funktioniert. Ich wollte nur die Antwort teilen, falls jemand anderes darüber hinwegkommt.