Problem: .NET-Code läuft von einem Verzeichnis, aber nicht eine andere, auf derselben Platte [geschlossen]

Question

Unsere Anwendung ist eine Hybrid-Win32 nicht verwalteten Anwendung und eine .NET 2.0 verwaltete Anwendung. Der Win32-Teil ist die wichtigste ausführbare Datei, die bei einigen Punktlasten und beherbergt die .NET 2.0 Runtime und lädt einige verwaltete Module neue WinForms Fenster zu öffnen.

Wir haben unseren Anteil an CASPOL-Typ Probleme gehabt, aber heute haben wir ein sehr ausgefallenes Problem und ich hoffe, dass jemand mir einige Hinweise oder Ideen geben kann, oder im Grunde wirklich nur etwas, das einen Funken etwas auslösen würde, das würde uns helfen, dieses Problem zu beheben.

Auf einem Server durch citrix zugegriffen wird, wenn die Anwendung Dateien in einem Verzeichnis auf dem Desktop des aktuell angemeldeten Benutzers befindet sich befinden, die ein Server / Domain-Administrator ist, läuft das Programm gut. Die .NET-Fenster geöffnet, wie erwartet.

Wenn wir jedoch das Verzeichnis an die Wurzel derselben Platte zu bewegen, die in dem Server eine physische Festplatte ist (also kein SAN-Mapping oder irgendetwas, das einen CASPOL Befehl mein Wissen auslösen würde ) und halten alles andere gleich, denselben Benutzer, die gleiche Konfiguration, etc. , stürzt die Anwendung still, wenn wir versuchen, die .NET-Fenster aufzurufen. Er stürzt haft nur verschwinden, was es so etwas wie ein Stack-Überlauf sein könnte vermuten lässt. Wir suchen in einigen Teilen der App das Hinzufügen Protokollierung vielleicht in der Lage sein, um herauszufinden, was passiert, und wo, aber ich bin Entsendung diese Frage auch hier.

Bisher verifiziert haben wir, dass es keine Merkwürdigkeiten in der CASPOL Zugriffsliste sind, nichts ungerade im NGEN Cache (ich vielleicht dachte es wurde aus der Zeit vor beschädigt Bilder, wenn der Server Besitzer mit ihm gespielt hatte), und keine Merkwürdigkeiten im GAC (wir GAC nicht für die Baugruppen verwenden).

Zusammengefasst:

• Wenn das Programm von U ausführen: \ Dokumente und Einstellungen \ Benutzername \ Desktop \ Verzeichnis, es funktioniert
• Wenn es von U ausgeführt wird: \ Verzeichnis, es funktioniert nicht
• U: ist eine physische Festplatte auf dem Server
• Keine offensichtlichen Merkwürdigkeiten in NGEN oder GAC Caches
• Der richtige .NET-Runtime installiert ist, hat die richtigen Dateien für unsere Anwendung installiert werden (und in der Tat gut funktionieren, wenn von der Stelle auf dem Desktop ausgeführt wird)

Jeder mit etwas, das helfen könnte?

Edit: Problem mit verschiedenen / anderen Informationen hier> Wieder gefragt, und‚Spa gelöst‘.

Answer 1

Mein erster Stich wäre Prozessmonitor von MS-Sysinternals laufen und schauen, was Anrufe / Ergebnisse sind für diese beiden Gelegenheiten. das würde Ihnen einige Hinweise Vielleicht arbeiten (unterschiedliche Ergebnisse für den gleichen Anruf, einige Fehler in dem Problem laufen, die nicht im Guten sind ...)

Sie können downloaden Prozessmonitor von MS: http://technet.microsoft.com/en-us/sysinternals/bb896645. aspx

Answer 2

Ich hatte gerade ein solches Problem einige Zeit zurück. Nach langem Haar ziehen, fand ich das Problem.

Seien Sie sehr vorsichtig, wenn Sie Process.Start () oder alle solche Anrufe, weil je nachdem, wie Sie es starten sie eine Vielzahl von Ordnern als Arbeitsumgebung (Strompfad verwenden können, Systemumgebung und so weiter.

Answer 3

Mein erster Gedanke ist, dass man dort sicherstellen muß, sind keine relativen / absoluten Pfade für Verweise auf Baugruppen im Programm definiert, Dateien, usw., die Probleme verursachen, wenn Sie das Stammverzeichnis der Anwendung zu bewegen.

Answer 4

Ist es möglich, dass sie im Zusammenhang mit Benutzer-Rechten? Führen Sie es von LUA Buglight zu überprüfen. Auch wenn es nicht direkt verwandt ist, auch das Werkzeug kann einige nützliche Hinweise geben.