Probleme mit Pfaden

Hallo,

ich habe eine DLL geschrieben in der ich ein .Batchfile aufrufe und eingaben dahin schicke. Das Funktioniert auch sehr gut. Ich musste dafür aber im Konfigurationsmanager die Plattform von "Any CPU" auf "x64" ändern damit es funktioniert. Das konnte ich mir bisher auch noch nicht erklären.

Wenn ich den Pfad des Batch-Files jetzt aber auf eine andere Festplatte festlege, dann funktioniert es nicht mehr. Kann mir jemand erklären wieso das so ist? (Der Pfad passt und da gibt es keinen Fehler das dieser falsch wäre). Die Datei liegt neu im "öffentlich" Ordner, wo die Zugriffsrechte passen sollten.

Gruß

Stefan

Plattform von "Any CPU" auf "x64" ändern damit es funktioniert. Das konnte ich mir bisher auch noch nicht erklären.

Weil das ein Effekt ist, wie die Prozessverwaltung und die Shell von Windows funktioniert.
WOW64 Implementation Details

Kann mir jemand erklären wieso das so ist?

Man kann da nun aus der Ferne nur raten:
Batch Files arbeiten (wie jeder Prozess unter Windows) mit einem Working Directory und das passt nun nicht mehr.

ProcessStartInfo.WorkingDirectory Property

Danke für die schnelle Antwort. Als ich den Begriff "Working Directory" gelesen habe, ist es mir auch direkt wieder eingefallen.

Das Thema mit der Prozessverwaltung und die Shell von Windows habe ich noch nicht ganz verstanden. Ich habe mein Tool jetzt auch so umgestellt das ich kein Batch-File mehr nutze sondern einfach die cmd.exe. Die hat aber das selbe Problem. Aber ich wollte von dem Batch-File Abstand gewinnen, damit es allgemeiner ist. 
Kannst du mir zu der WOW64 oder zu dem Thema allgemein vielleicht ein paar mehr Infos geben? Ist das WOW64 eine Möglichkeit eine 32-Bit Anwendung vorzugeben damit er das in dieser Version starten muss?

Oder ist es möglich Einfluss darauf zu nehmen, wie die DLL später aufgerufen wird? Weil scheinbar, wenn die DLL von einem dritt Programm aufgerufen wird was keine Visual Studio Anwendung ist, funktioniert es ja nicht mehr. Da würde ich davon ausgehen das diese Anwendung dann die DLL nicht mehr als x64 oder x86 aufrufst, oder liege ich da falsch?

Zitat von Stefan7907

Kannst du mir zu der WOW64 oder zu dem Thema allgemein vielleicht ein paar mehr Infos geben? Ist das WOW64 eine Möglichkeit eine 32-Bit Anwendung vorzugeben damit er das in dieser Version starten muss?

Naja, deswegen hab ich Dir den Link gegeben. Wenn Du wissen willst, wie die Prozessverwaltung unter Windows funktioniert, dann les Dir das in den Windows Docs nach. Macht ja wenig Sinn, wenn ich Dir das nun raus kopier. Oder nimm eine AI Deiner Wahl, die Dir eine Zusammenfassung schreibt.

Ist Deine Anwendung x86, isses nen 32-Bit Prozess. Bei x64 eben ein 64-Bit Prozess.
AnyCPU ist nur eine Kompilatsinfo, dass die Anwendung auf beiden Zielplattformen funktioniert. Du kannst aber aus Sicht der Anwendung dann nicht entscheiden, als was sie läuft. Das entscheidet dann die Zieplattform selbst. Auf der Zielplattform kann man das über CorFlags ebenfalls beeinflussen, aber eben nicht der Entwickler.

Unter Windows sind die ausführenden Pfade von x86 und x64 unterschiedlich. Ergo hat das einen Einfluss auf alle Anwendungen, die darauf angewiesen sind, zB die Shell. Daher wenn immer möglich einfach die Shell weg lassen, egal ob Shell als Anwendung oder als Script.
Geht das nicht, dann musst Du damit Leben wie die Shell und Windows eben funktionieren: leg dich auf x86 oder x64 fest.

Oder ist es möglich Einfluss darauf zu nehmen, wie die DLL später aufgerufen wird?

Nein

Weil scheinbar, wenn die DLL von einem dritt Programm aufgerufen wird was keine Visual Studio Anwendung ist, funktioniert es ja nicht mehr.

An VS wirds mit Sicherheit nicht liegen.

Da würde ich davon ausgehen das diese Anwendung dann die DLL nicht mehr als x64 oder x86 aufrufst, oder liege ich da falsch?

Es ist aus der Ferne nicht zu erkennen und zu beantworten, wer hier was aufruft. Eventuell liegts auch gar nicht am Working Directory - aber da wir quasi 0 Infos haben, isses einfach nur Raten mit der Glaskugel.

Eine DLL wird eh nicht aufgerufen, sondern in ein Prozess gepackt und dieser Prozess hat dann die passende Zielplattform, oder eben nicht.