[erledigt] Datei aus Application.StartupPath laden => Zugriff auf den Pfad wurde verweigert (Win7)

Hallo Leute!
Ich habe ein Problemchen, das für mich zz nur unkomfortabel anzugehen ist, da ich kein Windows 7 direkt zur Verfügung habe.
Daher frage ich einfach mal, ob mir jemand etwas dazu sagen kann:
Mit VS2010 erstelle ich ein Setup, das eine Datei Help.rtf ins das Verzeichnis "Anwendungsordner"kopiert. (Wie alle anderen Dateien, sprich exe und dlls, auch)

Im Programm lade ich die Datei so ein:

 
string filename = Application.StartupPath + "\\Help.rtf";
try
{
  FileStream stream = new FileStream(filename, FileMode.Open);
  if (stream != null)
  {
    richTextBoxHelp.LoadFile(stream, RichTextBoxStreamType.RichText);
  }
}
catch
{
  richTextBoxHelp.Text = String.Format("Helpfile \" {0} \" not found.", filename);
}

unter Vista: alles gut.
Win 7: Datei wird nicht gefunden. z.B. "C:\program files\OWi Sudoku\Help.rtf"
Obwohl die Datei da ist.
Falls virtuelle Pfade o.ä. unter Win7 einen anderen echten Pfad generieren, was nehme ich anstelle von StartupPath bzw. wie muss ich das Setup umgestalten?
Ich bin für Antworten dankbar!

schnuggelbugge

Hallo schnuggelbugge,

Windows 7 (aber auch schon Vista) zeigt im Windows-Explorer für bestimmte Verzeichnisse deutsche Namen an, die auf der Platte englisch heißen. Bei dir wird aber schon der englische Name angezeigt und das ist auch gut so. Es sieht also nicht so aus, als wären die virtuellen Namen die Ursache, zumal - wie gesagt - Vista auch schon so arbeitet.

Um ganz sicher zu gehen, kannst du mal schauen, was für Pfade bei den alternativen Wegen in [FAQ] Pfad zur eigenen Anwendung (EXE) ermitteln ermittelt werden.

herbivore

Hallo Herbivore!

Vielen Dank für deine Antwort.

Meine Frage war falsch bzw. mein Problem ist ein anderes.
Ich habe mir mal die Exception Message anzeigen lassen.
"Der Zugriff auf den Pfad wurde verweigert."
Die Datei ist da, der Pfad stimmt.
Man kann unter Windows 7 nicht auf Dateien in "program files" LESEND zugreifen?
Was macht man denn da am Besten?
Setup-Erstellung ist ja sicher eine Wissenschaft für sich, aber das "Problem" müssten doch zig "alte" Programme auch haben, oder?
Oder muss man nun das Setup alle Dateien, auf die man programmtechnisch zugreifen möchte in ein "spezielles" Verzeichnis installieren lassen und dort zugreifen? Welches Verzeichnis ist das im Setup-Projekt und wie lautet es C#-technisch?

viele Grüße,
schnuggelbugge

(Offtopic @ Herbivore: Bist du Vegetarier? "Kräuterfresser"?)

Okay - ich habe gestöbert und folgendes, wie befürchtet, gefunden:

Das hängt mit dem UAC User Access Control zusammen.
Was ich nicht vermutet hätte (und auch nicht ganz einsehen möchte) ist, dass man ohne Berechtigung auch noch nicht mal in "program files" LESEN darf.

Wenn man also das Programm "als Administrator ausführen" lässt, klappt der lesende Zugriff.
Das ist in meinem Falle nicht akzeptabel/praktikabel.
Eine Manifest-Datei möchte ich daher auch nicht beilegen.

Also, auch wenn ich es unschön finde:
Man erstellt im Setup unter "Dateisystem" einen Ordner "Ordner für Anwendungsdaten des Benutzers". Darunter ein Verzeichnis "unterverzeichnis".
Bei der gewünschten Datei gibt man den o.g. Ordner als "Folder" (also Zielverzeichnis) an. (Das Unterverzeichnis ist natürlich optional, aber wer knallt seine Dateien schon mitten in die "root"?)

und in der Anwendung dann:

string Path = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData); 
string filename = System.IO.Path.Combine(Path, "unterverzeichnis\\datei");

Warum finde ich das unschön? Entweder verstehe ich das falsch, oder für jeden User wird nun eine Datei, in meinem Falle eine Hilfe-Datei, kopiert. Das sind zwar hier keine 12 GB, aber es sieht so aus, als sei das nicht nur "Best Practice" sondern auch anders gar nicht möglich.

Wenn's doch anders oder besser geht, nur raus damit!

schnuggelbugge

Was ich nicht vermutet hätte (und auch nicht ganz einsehen möchte) ist, dass man ohne Berechtigung auch noch nicht mal in "program files" LESEN darf.

etwas Quellcode wäre natürlich von Vorteil

Hallo schnuggelbugge,

Fragen zu fehlgeschlagenem schreibenden Zugriff im Programmverzeichnis kann man schon fast als Standard bezeichnen. An Fragen zu Problemen mit lesendem Zugriff kann ich mich nicht erinnern. Außerdem hast du natürlich recht, dass massig bestehende Anwendungen auf die Nase fallen würden, wenn der lesende Zugriff nicht mehr möglich wäre.

Insofern liegt natürlich die Vermutung nahe, dass die Einstellungen bei dir anders sind als der Standard.

Aus meiner Sicht spricht nichts dagegen, Dateien, die das Programm lesend benötigt ins Programmverzeichnis - oder zumindest in ein Unterverzeichnis davon - zu legen.

Dass du dir die Exception nicht sofort angeschaut und einfach deine (falsche) Vermutung gepostet hast, war natürlich nicht so schön. Für dieses mal Schwamm drüber, für die Zukunft schau bitte mal in [Hinweis] Wie poste ich richtig? Punkt 5.

herbivore

Dasselbe Problem habe ich auch mit einer SQLServerCE-Datenbank, die im selben Verzeichnis liegt, wie die eigentliche Assembly. Nur mit Adminrechten läuft das Programm fehlerfrei. Ein Manifest ist ja mit zwei Klicks eingebettet und dann wird ja nur noch der AuthenticationLevel (oder wie es auch heißt) geändert. 2 Minuten Arbeit. Allerdings finde ich den Klick bei der UAC auch unzumutbar und ich überlege mir gerade eine Lösung mit verschieben der DB in das Userverzeichnis, wo sie allerdings für alle anderen Nutzer des Rechners auch erreichbar sein muss.

Ist vermutlich auch kein besonderer Aufwand, aber wenn man zu Hause zu nichts kommt, stellt es doch eine Hürde dar 😁

Quellcode? siehe Post.

Hallo schnuggelbugge,

new FileStream(filename, FileMode.Open);  

... öffnet die Datei zum Lesen und zum Schreiben. Verwende FileAccess.Read oder eine andere Methode, die die Datei nur zum Lesen öffnet.

herbivore

Hallo

Insofern liegt natürlich die Vermutung nahe, dass die Einstellungen bei dir anders sind als der Standard.

Was kann man da einstellen? Sowohl bei der inzwischen vorhandenen Installation von win7 (Ultimate) bei mir als auch bei einer "externen" Installation ergab sich nach Durchführen des Setups das geschilderte Problem.

schnuggelbugge

P.S.: Danke für den Schwamm.

Hallo schnuggelbugge,

mit den Einstellungen hat es wohl doch nichts zu tun. Ich bin mir sicher, dass ich die tatsächliche Lösung in meinem letzten Beitrag genannt habe.

herbivore

Danke Herbivore!

Da hatten sich unsere Posts gerade überschnitten.

Deine Antwort ist super und macht natürlich auch Sinn.
Komisch, alle sehen den Quelltext und keiner kommt drauf, erst mit nachdenken.

So klärt es sich aber natürlich schön auf und alles ist gut.

Klasse Arbeit!

schnuggelbugge