SHGetKnownFolderPath / Environment.GetFolderPath () gibt einen falschen Wert für öffentliche Dokumente zurück

9

Beim Versuch, das Verzeichnis CommonDocuments aufzulösen, ist ein seltsamer Fehler aufgetreten. Es wird weiterhin in das falsche Verzeichnis aufgelöst, nachdem das CommonDocuments-Verzeichnis mithilfe des Windows-Explorers an den neuen Speicherort umgeleitet / verschoben wurde (Eigenschaften -> Pfad aus dem Kontextmenü).

Ein minimaler funktionierender Code wäre:

%Vor%

Erwartetes Verhalten:
Ausgabe ist D:\TestDocuments

Tatsächliches Verhalten:
Ausgabe ist C:\Users\Public\Documents

  

Keine; P / Invoke == & gt; C: \ Benutzer \ Öffentliche \ Dokumente
  DONT_VERFIY, ALIAS_ONLY; P / Invoke == & gt;   NOT_PARENT_RELATIVE, DEFAULT_PATH; P / Invoke == & gt; C: \ Benutzer \ Öffentlich \ Dokumente

Der korrekte Wert wird in der Windows-Registrierung (HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Explorer \ Shellordner \ Gemeinsame Dokumente) gespeichert, aber von SHGetKnownFolderPath (oder Environment.GetFolderPath )

Betriebssystem: Windows 7 Professional x64
.NET Framework v4.0.30319 Die Anwendung wurde für die x86-CPU

kompiliert

Was ich bisher versucht habe:

  • meine Anwendung neu starten
  • Neustart des Computers
  • Aufruf von Environment.GetFolderPath(Environment.SpecialFolder.CommonDocuments);
  • direkte Aufrufe an Win32-API SHGetKnownFolderPath

EDIT 2 Schritte zum Reproduzieren:

  1. deaktivieren Sie die Benutzerkontensteuerung auf Ihrem Computer [und starten Sie sie neu!]
  2. gehe zu C: \ Benutzer \ Öffentlich \
  3. Klicken Sie mit der rechten Maustaste auf den Ordner "Öffentliche Dokumente" und wählen Sie Properties
  4. Wählen Sie die Registerkarte "Pfad"
  5. klicken Sie auf "Move ..." und wählen Sie einen (neuen) Ordner auf dem Laufwerk D: namens TestDocuments
  6. klicken Sie auf "Übernehmen"
  7. Akzeptieren, um alle Dateien an den neuen Speicherort zu verschieben, starten Sie das Minimale Anwendung oben
yas4891 01.04.2015, 08:14
quelle

1 Antwort

4

tl; dr: Das Verhalten ist von Entwurf und wird nur angezeigt, wenn Sie eine Assembly ausführen, die für x86-CPUs auf einem x64-Betriebssystem kompiliert wurde

Längere Version:
Environment.GetFolderPath(Environment.SpecialFolder.CommonDocuments) greift auf die 32-Bit-Struktur der Windows-Registrierung zu.
Der tatsächliche Pfad zum Ordner wird in der 64-Bit-Struktur gespeichert. Das Problem wurde an das Windows-Team weitergeleitet und möglicherweise in einer zukünftigen Windows-Version behoben.

Weitere Informationen finden Sie unter der Microsoft Connect-Bericht

Problemumgehung Erstellen Sie eine Konsolenanwendung mit dem folgenden Code und kompilieren Sie sie für ANY CPU

%Vor%

Rufen Sie es dann von Ihrer Hauptanwendung aus:

%Vor%

Dies startet die ausführbare Datei ANY CPU , die nur den gewünschten Pfad zur Standardausgabe ausgibt. Die Ausgabe wird dann in der Hauptanwendung gelesen und Sie erhalten den tatsächlichen Pfad.

    
yas4891 13.09.2011, 14:44
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset .NET-Framework-Kompatibilität: 3.5 SP1 & 4.0-Clientprofil