"Installationsverzeichnis muss sich auf einem lokalen Laufwerk befinden" msi-Installationsfehler

14938
Johny Skovdal

Einige unserer Benutzer in unserer Organisation haben begonnen, einen merkwürdigen Fehler bei der Installation unseres Produkts zu melden (Produktdetails wurden im Screenshot geändert):

Screenshot of the danish error message

Die ursprüngliche Fehlermeldung in Englisch lautet "Installationsverzeichnis muss sich auf einem lokalen Laufwerk befinden".

Das Ändern des Pfads in etwas ohne Leerzeichen, alternative Stammordner oder sogar andere physische Laufwerke auf dem Computer ändert nichts. Das Installationsprogramm besteht weiterhin darauf, dass der Pfad kein lokaler Pfad ist.

Dieses Installationsprogramm wird mit WIX erstellt, und der bestimmte Schritt im Prozess wird mit der benutzerdefinierten Aktion erstellt WixUIValidatePath. Zuvor wurde ein Fehler eingereicht, der auch darauf hinweist, dass der Fehler mit Einschränkungen für das Installationsprogramm zusammenhängt ( danke an peterflynn auf GitHub, dass Sie mich in diese Richtung weisen ).

Das Problem tritt nur auf einigen Computern auf und es scheint, dass niemand das Problem in Windows 10 hat. Ich konnte nicht testen, ob es in anderen Windows-Versionen einen Teil von 8.1 gibt, da dies und Windows 10 die einzigen Versionen sind, die wir verwenden Lauf.

3
In welcher Beziehung steht das [wix] -Tag zu dieser Frage? CharlieRB vor 8 Jahren 0
Wird es einmal im conputer bearbeiten. Siehe Antwort für Details. @ CharlieRB Johny Skovdal vor 8 Jahren 0
NP ... Ja, ich sehe in der Antwort den Hinweis auf Wix. Dies ist eine gute Frage und Antwort. Ich wollte nur sicherstellen, dass der Tag für die Frage wichtig ist. In der Frage sollte etwas erwähnt werden. CharlieRB vor 8 Jahren 0
@CharlieRB: Genau, ich habe dieses Detail einfach vergessen, also danke, dass du mich darauf aufmerksam gemacht hast! :) Es sollte jetzt klarer sein. Johny Skovdal vor 8 Jahren 0

1 Antwort auf die Frage

5
Johny Skovdal

After much debugging we narrowed it down to problems with rights to temp folders with the current user. Different steps resolved the issue on different computers. Here I will be listing the fixes from the least to the most invasive approaches:

  1. Ensure that the installer is run as administrator
    This is something we already require, but some users tend to forget this. This is also the most common solution to the issue I've found when searching for a solution.
    The simplest way to ensure this, is by pressing the WinKey and type cmd to find the command prompt, and then press CTRL + SHIFT + ENTER to open the command prompt as administrator, then navigate to the msi folder (for navigation instructions, see this link) and run it from there.
  2. Manually install KB3072630
    Some of our users had, for some reason, not correctly received this particular update from MS which seemed to fix the issue! This was where most users got their problem resolved.
  3. Run the installer silently
    The bug is related to a WIX UI component, so running the the MSI silently will not activate the UI component, and therefore the bug will not be triggered either. You can do this through the commandprompt as specified in above step, but with these added parameters to the MSI:
    /qn+
    Thanks to Kr3m on GitHub for this approach
  4. Run the installer with UI check disabled
    The WIX UI component that bugs it all up can also be disabled. WARNING: This will also disable any sanity checks on the installation path, and might mess up the installation process! This can be done with another commandline parameter:
    WIXUI_DONTVALIDATEPATH="1"
    Thanks to peterflynn on GitHub for this approach
  5. Disable LUA
    The only sure way to remove the issue, was to disable the LUA completely, which was the standard for some of our environments, to be able to work with legacy features. Disabling LUA completely requires manual changes to the registry, so be sure that you know what you are doing, and the consequenses of it as well. Instructions can be found here on MS' forum.

One thing we did not test, that might solve it as well, is to recreate the user on the computer, because we think it has to do with access rights to the users own temp folders. They might be recreated correctly through a recreation of the user.

Verwandte Probleme