2017-10-17 3 views
1

Ich habe Probleme, die Reihenfolge der Betrieb des WiX-Setups zu verstehen.
Wenn Sie versuchen, einen Registrierungsschlüssel zum Hinzufügen eines Menüeintrags zum Windows Explorer-Kontextmenü und simultan mit CustomActions zu erstellen, wird der Registrierungsschlüssel nicht hinzugefügt.
Wenn ich jedoch nur versuche, den Schlüssel zu registrieren, funktioniert es (jeder CustomAction-Code ist auskommentiert).WiX Setup erstellt einen Registrierungsschlüssel funktioniert nicht, wenn auch CustomActions

  1. In meinem Product.wxs Ich habe erhöhte priviliges Set mit
    <Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" InstallPrivileges="elevated"/>. In meinem <Feature> habe ich <ComponentRef Id="RegistryEntries"/> referenziert.

  2. Dies ist der Code für den Registrierungsschlüssel

    <Fragment> 
         <Directory Id="TARGETDIR" Name="SourceDir"> 
         <Component Id="RegistryEntries" Guid="*"> 
          <RegistryKey Root="HKCR" 
             Key="Excel.CSV\shell\Use MyConverter\command" 
             ForceCreateOnInstall="yes" 
             ForceDeleteOnUninstall="yes"> 
          <RegistryValue Type="string" Value="[INSTALLLOCATION]$(var.SolutionName).exe %1" 
              KeyPath="yes"/> 
          </RegistryKey> 
         </Component> 
         <Directory Id="ProgramFilesFolder"> 
          <Directory Id="HSZLG" Name="MyConverter"> 
          <Directory Id="INSTALLLOCATION" Name="$(var.SolutionName)" /> 
          </Directory> 
         </Directory> 
         <!--<Directory Id="ProgramMenuFolder"> 
         <Directory Id="Shortcuts" Name="MyConverter" /> 
         </Directory>--> 
        </Directory> 
        </Fragment> 
    
  3. Im jetzt auch mit den folgenden benutzerdefinierten Aktionen zu erstellen:

    <CustomAction Id="UnregisterImportFormat" BinaryKey="WixCustomAction" DllEntry="UnregisterImportDefinition" Execute="deferred" Impersonate="no" Return="check" /> 
    <CustomAction Id="PropertiesForUnregisterImportFormat" Property="UnregisterImportFormat" Return="check" 
           Value="app=AB;key=10000P1000" /> 
    

    und sie in der <InstallSequence> wie folgt aufrufen:

    <InstallExecuteSequence> 
        <Custom Action="PropertiesForRegisterImportFormat" Before="RegisterImportFormat" /> 
        <Custom Action="RegisterImportFormat" Before="InstallFinalize">(NOT Installed) OR REINSTALL</Custom> 
    
        <Custom Action="PropertiesForUnregisterImportFormat" Before="UnregisterImportFormat" /> 
        <Custom Action="UnregisterImportFormat" Before="InstallFinalize">REMOVE</Custom> 
    </InstallExecuteSequence> 
    

Es würde mich freuen, wenn jemand darauf hinweisen könnte, was ich hier falsch mache.

+0

Dies ist auf meiner erforderlichen Leseliste: http://www.installsite.org/pages/en/isnews/200108/index.htm –

Antwort

0

Es gibt Schwierigkeiten mit (verzögerten) benutzerdefinierten Aktionen, die ohne Identitätswechsel ausgeführt werden, sowie mit dem HKCR-Schlüssel, da HKCR kein tatsächlicher Registrierungsspeicherort ist - es handelt sich um eine Zusammenführung des interaktiven Benutzers und HKEY_LOCAL_MACHINE \ Software \ Classes. Dies geht ins Detail:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms724475(v=vs.85).aspx

und der Code für benutzerdefinierte Aktion wird mit dem Systemkonto ausgeführt wird (latente, kein Identitätswechsel), die mehr Verwirrung ist das Hinzufügen, um den Registrierungsschlüssels Sie erstellen. Wie die MSDN Anmerkung sagt:

„Um die Einstellungen für den interaktiven Benutzer zu ändern, speichern Sie die Änderungen unter HKEY_CURRENT_USER \ Software \ Classes statt HKEY_CLASSES_ROOT“

und ich nehme an Ihrem Code HKCR zu verwenden versucht. Windows Installer wird zum Schreiben dieser Registrierungseinträge bevorzugt, weil "es einfach funktioniert". Code, der mit dem Systemaccount ausgeführt wird, der in HKCR schreibt, ist unzuverlässig. Wenn Sie also wirklich Code verwenden müssen (und Sie sollten das nicht), versuchen Sie HKEY_LOCAL_MACHINE \ Software \ Classes.

Verwandte Themen