2012-08-24 18 views
12

Die folgende Verzeichniseinstellung funktioniert perfekt für mich.Wie installiere ich in den Ordner LocalAppData?

<Directory Id='TARGETDIR' Name='SourceDir'> 
    <Directory Id="ProgramFilesFolder"> 
    <Directory Id='INSTALLDIR' Name='MyApp'/> 
    </Directory> 
</Directory> 

Allerdings, wenn ich versuchte, zu ändern "Program" auf "LocalAppDataFolder", ich habe viele Fehler, wenn light mit meinem msi zu verbinden und erzeugen:

D:\runGroup.wxs(53) : error LGHT0204: ICE38: Component cmpA5561BE36D80EB58252E69DDA0C2FF8C installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file. D:\main.wxs(38) : error LGHT0204 : ICE64: The directory INSTALLDIR is in the user profile but is not listed in the Remove File table.

Sieht aus wie " LocalAppDataFolder "ist für WiX nicht akzeptabel, während ich glaube, dass es eine der Systemordnereigenschaften ist, die in here definiert ist.

Was soll ich für den Ordner LocalAppData verwenden?

+0

Mein Tipp: Installieren Sie nicht in irgendeinem Benutzerprofil-Ordner. Installieren Sie auf [ProgramFilesFolder] und lassen Sie das Betriebssystem umleiten. Jedes Betriebssystem könnte dies anders machen und Ihre "unter der Haube" Fixes werden zweifellos fehlschlagen. Wenn der Ordner nicht vom Betriebssystem umgeleitet wird, sollte die MSI-Referenzzählung in der Lage sein, mehrere Installationen für verschiedene Benutzer im selben Ordner vorzunehmen. Stellen Sie nur sicher, dass Sie keine Lese-/Schreibdateien haben, die Sie im Ordner ändern. Ihr Installationsordner sollte nur gelesen werden. Kämpfe nicht gegen Windows 'Idiosyncrazies - es beißt mit Rache zurück. –

+0

Das Problem hier ist, ich weiß nicht, wie [ProgramFilesFolder] auf den Ort umleiten, der für die Installation pro Benutzer sein sollte. Deshalb musste ich einen Workaround finden. – Deqing

+0

Ja, und du solltest es überhaupt nicht umleiten :-). Windows könnte Sie auf Vista, Windows 7, Windows 8 usw. auf verschiedene Arten weiterleiten ... Windows Installer ist gefährlich zu bekämpfen - es wehrt sich. Sie können die Installation auf [ProgramFilesFolder] auch für eine Installation pro Benutzer fortsetzen, und einige Windows-Versionen leiten sie möglicherweise automatisch um, andere installieren möglicherweise ProgrammeFilesFolder. Verwechseln Sie das nicht, lassen Sie es so laufen, wie Windows es vorschreibt. –

Antwort

1

Ok, fand nur, dass wir es durch Überschreiben „Program“ tun können:

<SetProperty Id="ProgramFilesFolder" Value="[LocalAppDataFolder]" Before="CostFinalize"><![CDATA[NOT Privileged]]></SetProperty> 

Eine andere Sache zu tun ist, in <Package> brauchen wir InstallPrivileges-limited einzustellen.

Nun, ich kann keinen Grund sehen, warum "ProgramFilesFolder" direkt verwendet werden kann, während "LocalAppDataFolder" nicht kann.

+0

Weil Sie dies nicht tun müssen. Es wird automatisch auf Win7 umgeleitet. –

+0

Der ProgramFilesFolder wird nicht in meinem Win7 umgeleitet. Ich habe versucht, InstallPrivileges sowohl mit 'limited' als auch mit dem Default-Wert zu installieren, alle setzen den% ProgramFilesFolder% auf 'C: \ Programme (x86)'. Wie löse ich diese Weiterleitung aus? Und noch eine Frage, beachten Sie, dass in WixUI_Advanced der Installationspfad für pro Benutzer explizit auf% LocalAppData% \ Apps \ ProgramName gesetzt wurde. Also, welche offizielle Version eines Programms sollte pro Benutzer installiert werden? '% LocalAppData% \ Apps' oder'% LocalAppData% \ Programs'? – Deqing

+1

Deqing, diese Lösung sieht gefährlich aus - ich bin überrascht, dass Windows Installer Sie tatsächlich dazu veranlassen wird. –

2

Installieren Sie pro Benutzer oder Maschine? Auf welche OS-Versionen zielen Sie auch ab? Vielleicht haben Sie lesen möchten:

Authoring a single package for Per-User or Per-Machine Installation context in Windows 7

+0

Ich installiere pro Benutzer, deshalb brauche ich LocalAppData in der Verzeichnisstruktur. Und es wird auf Win7 installiert werden. Für mich ist der einzige Weg, 'SetProperty' zu verwenden, wie ich zuvor beschrieben habe. – Deqing

+0

Laut diesem Artikel installiert Per-User auf Win7 mit ProgramFilesFolder wird automatisch zu LocalAppData \ Programs umgeleitet. Funktioniert das nicht für dich? –

+0

Ich habe gerade eine Testbenutzerinstallation mit InstallShield erstellt und sie mit [ProgramFilesFolder] Mein Firmenname \ Mein Produktname eingerichtet und sicher, dass es unter C: \ Benutzer \ Chrpai \ AppData \ Lokal \ Programme \ Mein Firmenname installiert ist \ Mein Produktname –

7

ich eine Anwendung konvertiert sich von einem perMachine installieren eine benutzerspezifische installieren sein. Um die Installation richtig zu konvertieren, musste ich einen Registrierungsschlüssel für jede der Komponenten hinzufügen, die ich habe.

Ursprünglich hatte ich folgendes:

<Component Id="C.MyExe"> 
    <File Id="Fi.MyExe" Name="$(var.MyExe.TargetFileName)" Source="$(var.MyExe.TargetPath)" DiskId="1"> 
    <Shortcut Id="SC.StartMenu" 
       Directory="D.ApplicationMenuDir" 
       Name="$(var.AppName)" 
       WorkingDirectory="INSTALLDIR" 
       Icon="MY_ICON.ico" 
       IconIndex="0" 
       Advertise="yes" 
     /> 
     ... 

Wenn ich die exe-Komponente für den Benutzer installieren zog ich etwas tun musste:

<Directory Id="LocalAppDataFolder" Name="AppData"> 
    <Directory Id="MyAppDirectory" Name="$(var.AppName)"> 
    <Component Id="C.MyExe" Guid="{MY_GUID}"> 
     <CreateFolder /> 
     <RemoveFolder Id="RemoveMyAppDirectory" On="uninstall" /> 
     <RegistryKey Root="HKCU" Key="Software\MyCompany\MyApp"> 
     <RegistryValue Name="MainExe" Value="1" KeyPath="yes" Type="integer" /> 
     </RegistryKey> 
     <File Id="Fi.MyExe" Name="$(var.MyExe.TargetFileName)" 
      Source="$(var.MyExe.TargetPath)" DiskId="1" Checksum="yes"> 
     </File> 
    </Component> 
    ... 

Der wichtigste Teil ist, dass Sie muss einen Registrierungsschlüssel hinzufügen, der auf HKEY_CURRENT_USER zeigt. Ich habe einen Registrierungswert für jede Komponente hinzugefügt, der angibt, dass die Komponente installiert ist.

Ich musste auch entfernen: Advertise="yes".

+0

Mir wurde gesagt, dass Sie ICE38 ignorieren können, da dies nur für gemischte Benutzer- und Maschinenstandorte gilt und nicht für eine reine Einzelplatzinstallation. Siehe [hier] (http://stackoverflow.com/a/21715783/623561). – Wes

1

Ich hatte dieses Problem in letzter Zeit. Ich wollte meinen Installer von pro-Maschine zu einem pro-Benutzer umwandeln, bekam aber ICE38. Ich fragte nach wix-Benutzern und eine Meinung war, dass ICE38 ignoriert werden kann, da dies als eine Überprüfung für Installationen pro Maschine gedacht war.

Siehe the discussion at wix-users.

Da dies der Fall ist, ist ICE38 (meiner Meinung nach) falsch und Sie werden es ignorieren wollen. ICE38 impliziert, dass Sie Ressourcen pro Benutzer im Kontext einer Installation pro Maschine installieren, dies jedoch nie überprüfen.

Das Erstellen einer Benutzerinstallation erfordert, dass Sie ICE38 ignorieren, da es für diese Welt niemals genau sein wird.

[Bearbeiten] Sieht aus wie Sie helfen here bekam.

Von Peter Shirtcliffe:

ist meine eigene, zwar unerfahren, das Verständnis der pro-Benutzer-Installationen:

Installation auf Unterverzeichnis von LocalAppDataFolder ist vollkommen in Ordnung in einem pro Benutzer MSI. Aufgrund bestimmter Szenarien im Zusammenhang mit Roamingbenutzern müssen Sie Komponenten hinzufügen, die Elemente für beliebige Verzeichnisse enthalten, die Sie unter LocalAppDataFolder erstellen. Deshalb erscheint ICE64 erscheint.

Der ICE38 Fehler ist etwas irreführend: da Sie pro Benutzer Installation haben, es ist sicher, so lange zu ignorieren, da der Benutzer keine alternativen Installationsort, die alle Benutzer gemeinsam ist, auswählen kann. ICE38 ist Prüfung für die Situation, in der mehrere Benutzer alle die gleiche Komponente auf den gleichen Pfad installieren.

Einfach Posting, um anderen Menschen (wie mir) zu helfen.