none
WindowsApps Relativer zu Absoluten Pfad RRS feed

  • Frage

  • Hallo, ich würde gerne eine StorageFile aus einen relativen Pfad laden. Genauer handelt es sich dabei um Initialdaten die in einer XML liegen. Allerdings verlangt die StorageFile, dass es ein absoluter Pfad sein muss. Aber wo bekomme ich den her? Am liebsten würde ich

    StorageFile File = StorageFile.GetFileFromPathAsync(@"BasicData\Initialdata.xml");

    verwenden. Ist aber leider nicht möglich.

    Gruß


    • Bearbeitet UrielMhezzek Sonntag, 7. Oktober 2012 17:06 Anzeige war fehlerhaft
    • Verschoben Ionut DumaModerator Freitag, 12. Oktober 2012 08:06 Frage uber WinRT (aus:Visual C#)
    Sonntag, 7. Oktober 2012 17:06

Antworten

  • Zum einen habe ich mitlerweilse selbst eine Lösung gefunden.

    StorageFile logo = await Windows.Storage.StorageFile.GetFileFromApplicationUriAsync(new Uri("ms-appx:///Imges/logo.png"));
    

    Der GetCurrentDirectory kann sich im laufe eines App-Lebens durchaus ändern. Ist also keine gute wahl.

    Und bei den Benutzerdaten ist keiner der genannten Verzeichnisse eine gute Wahl. Sollte die App mal gelöscht werden, werden auch alle drei Ordner ohne wenn und aber mit gelöscht. Die persistenten Daten sind dann futsch. Keine gute Idee von Microsoft.

    Daher werde ich meine Daten lieber in der Dokumentenbilbliothek lagern, da es bei mir auf dauerhafte Persistenz ankommt. Dinge die nach einer Deinstallation weg sein dürfen, werde ich natürlich im Local Folder lassen.

    • Als Antwort markiert UrielMhezzek Montag, 8. Oktober 2012 07:14
    • Tag als Antwort aufgehoben Marcel Roma Montag, 8. Oktober 2012 13:01
    • Als Antwort markiert UrielMhezzek Freitag, 12. Oktober 2012 14:31
    Montag, 8. Oktober 2012 07:14

Alle Antworten

  • string current = Directory.GetCurrentDirectory();
    string absolute = Path.Combine(current, @"BasicData\Initialdata.xml");
    
    StorageFile file = StorageFile.GetFileFromPathAsync(absolute);
    

    Sonntag, 7. Oktober 2012 22:21
  • Hallo,

    Benutzerdaten können in einer App als Dateien unter drei vorgegebenen Locations gespeichert werden:

    1. Windows.Storage.ApplicationData.Current.LocalFolder
    2. Windows.Storage.ApplicationData.Current.RoamingFolder
    3. Windows.Storage.ApplicationDate.Current.TemporaryFolder

    In jedem dieser Zielordner kann man Dateinamen mit oder ohne Ordnername erstellen, wie von dir gewünscht:

    async void ReadInitialData()
    {
       var file = @"BasicData\Initialdata.xml";
    
       StorageFolder roamingFolder = ApplicationData.Current.RoamingFolder;
    
       StorageFile initialDataFile = await roamingFolder.GetFileAsync(file);
       string text = await FileIO.ReadTextAsync(file);
    
       // ...
    }

    Den Pfad zum Roaming-Ordner erfährt man, indem man z.B. roamingFolder.Path auswertet. Hängt man da noch @"BasicData\Initialdata.xml" dran, so erhält man den vollen Pfad zur XML-Datei. Diesen Pfad kann man dann auch an StorageFile.GetFileFromPathAsync als Parameter übergeben.

    Gruß
    Marcel

    • Bearbeitet Marcel Roma Montag, 8. Oktober 2012 07:07 Rechtschreibung
    Montag, 8. Oktober 2012 07:04
  • Zum einen habe ich mitlerweilse selbst eine Lösung gefunden.

    StorageFile logo = await Windows.Storage.StorageFile.GetFileFromApplicationUriAsync(new Uri("ms-appx:///Imges/logo.png"));
    

    Der GetCurrentDirectory kann sich im laufe eines App-Lebens durchaus ändern. Ist also keine gute wahl.

    Und bei den Benutzerdaten ist keiner der genannten Verzeichnisse eine gute Wahl. Sollte die App mal gelöscht werden, werden auch alle drei Ordner ohne wenn und aber mit gelöscht. Die persistenten Daten sind dann futsch. Keine gute Idee von Microsoft.

    Daher werde ich meine Daten lieber in der Dokumentenbilbliothek lagern, da es bei mir auf dauerhafte Persistenz ankommt. Dinge die nach einer Deinstallation weg sein dürfen, werde ich natürlich im Local Folder lassen.

    • Als Antwort markiert UrielMhezzek Montag, 8. Oktober 2012 07:14
    • Tag als Antwort aufgehoben Marcel Roma Montag, 8. Oktober 2012 13:01
    • Als Antwort markiert UrielMhezzek Freitag, 12. Oktober 2012 14:31
    Montag, 8. Oktober 2012 07:14
  • Hallo UrielMhezzek,

    Du hast eine Frage beantwortet, die Du so nicht gestellt hast.

    Und auch das nicht ganz richtig, zumindest was dein Beispiel angeht. Natürlich kann man Code wie diesen schreiben:

    var uri = new Uri("ms-appx:///Assets/InitialData.xml");
    var initialDataFile = await StorageFile.GetFileFromApplicationUriAsync(uri);

    um auf eine Datei zu verweisen. Aber diese Datei befindet sich unter [Stammverzeichnis des lokalen App-Pakets]\[Unterordner]). Persistenz über die Lebensdauer einer App hinweg ist damit noch nicht erreicht.

    Der Zugriff auf das Dateisystem wurde in WinRT sehr eingeschränkt. Man muss damit leben und mit der Philosophie die dahinter steckt. Außer den o.g. ApplicationData-Ordnern kann man natürlich auch auf die unter KnownFolders aufgelisteten Verzeichnisse zugreifen, z.B. auf KnownFolders.DocumentsLibrary. (Zusätzlich kann man auf den Installationsordner mittels der Package-Klasse zugreifen oder in den Download-Ordner des Benutzers schreiben etc.) Aber: Das war zum einen nicht deine Frage (s. WindowsApps Relativer zu Absoluten Pfad), und zum anderen speichert man ganz allgemein keine Initialdaten in der Dokumentenbibliothek des Benutzers. DAS ist bad practice. Stell dir nur vor welche Versionierungsprobleme Du als Entwickler damit kriegen könntest (um nur einen der vielen nachteiligen Aspekte hier zu nennen), und wie die Dokumentenbibliothek aussehen würde, wenn jede App dort Daten zwischenlagern würde.

    Siehe auch:

    So wird's gemacht: Erstellen von Verweisen auf Inhalte
    Accessing app data with the Windows Runtime (Windows Store apps)

    Gruß
    Marcel



    • Als Antwort vorgeschlagen Ionut DumaModerator Freitag, 12. Oktober 2012 08:03
    • Bearbeitet Marcel Roma Freitag, 12. Oktober 2012 16:24 Link korrigiert
    Montag, 8. Oktober 2012 08:46
  • Da hast du mich eindeutig falsch verstanden. Ich will den relativen Pfad für den Initialdaten nutzen, die ich mit der App als statische Datei mitliefere. Aber um StorageFile zu verwenden brauch man einen absoluten Pfad. Und den wollte ich haben.

    Auf das andere Thema bin ich nur eingegangen, weil du mich überzeugen wolltest AppContainer zu verweden, die mich aber an dieser Stelle gar nicht interessieren.

    Die Daten aus den KnownFolders sind Custumized Daten vom Nutzer und der Nutzer soll mMn entscheiden dürfen ob er Daten in die er in meinen Falle Tage, Wochen oder Monate Herzschmerz hineingesteckt hat, gelöscht werden oder nicht. Welcher Nutzer weiß denn, dass auch alle gespeicherten Daten nach entfernen der App verschwunden sind? Ich wußte dies erst, als ich eine App versehentlich gelöscht hatte.Und ob sich jeder Entwickler darum gedanken macht, ob der Lebenszyklus z.B. der Savegames eines Spiels die App überdauern soll, sei noch dahin gestellt. Hier hätte MS von Anfang an, genau so einen Folder mit zur Verfügung stellen sollen. Ich denke einfach, dass es hier sehr viel ungehörte Meinungen zu gibt. Vor allem Meinungen die sich später erst beim Nutzer bilden. ICh finde es aber gut, das man eine MÖglichkeit geschaffen hat, beim Deinstallieren Apps komplett zu entfernen.

    Montag, 8. Oktober 2012 10:54
  • Hallo UrielMhezzek,

    Nochmals, zur Erinnerung, deine ursprüngliche Frage:

    "Allerdings verlangt die StorageFile, dass es ein absoluter Pfad sein muss. Aber wo bekomme ich den her?"

    Auf diese Frage habe ich geantwortet, und Du hast dann deine Lösung (?) gepostet mit der Bemerkung "bei den Benutzerdaten ist keiner der genannten Verzeichnisse eine gute Wahl". Das ist sachlich falsch.

    Nein, ich wollte dich von nichts überzeugen. SO MACHT MAN DAS EBEN unter WinRT. Lass doch den Benutzer selber entscheiden, ob er seine wertvollen Daten behalten möchte, gibt ihm die Möglichkeit sie auf Wunsch zu speichern.

    Daten für jeden Fall wegzuspeichern, womöglich noch ohne Benutzerinteraktion, auch nach dem Deinstallieren einer App, halte ich für eine fragwürdige Sache.

    Du kannst ja dem Benutzer über einen WCF Data Service permanenten und weltweiten Zugriff auf seine Daten anbieten, wenn er das möchte, mußt ihm also nicht den Dokumentenordner zumüllen in der Hoffnung dass er die App ein zweites Mal installieren wird.

    Auch ich findes es gut, dass Microsoft dafür gesorgt hat, dass kein Unfug mit dem Dateisystem getrieben wird und eine komplette Entfernung der Apps möglich ist.

    Gruß
    Marcel


    • Bearbeitet Marcel Roma Montag, 8. Oktober 2012 12:18 Link hinzugefügt
    Montag, 8. Oktober 2012 12:07
  • Also, halten wir einfach fest, ich habe meine Lösung für meinen Thread.

    Ob und wie MAN DAS EBEN MACHT kann kein externer Experte entscheiden, da er weder die Aufgabe noch das Nutzerverhalten kennt. Von dieser Meinung werde ich auch nicht abrücken. Er kann durchaus Richtlinien vergeben, an die ich mich im Übrigen komplett halte!

    Das der Nutzer darüber informiert wird, dass die Daten dauerhaft gespeichert werden, ist für mich klar. Zudem meine App davon leben wird, dass der Nutzer standartisierte Daten manipuliert und ergänzt.

    Montag, 8. Oktober 2012 12:53
  • Die Antworten in diesem Forum sollen nicht nur dem eigenen Projekt dienen, sondern auch zukünftigen Lesern, die am Thema interessiert sind. Da deine "Lösung" keine Antwort auf das Eingangsposting ist, habe ich den Antwort-Tag aufgehoben.
    Montag, 8. Oktober 2012 13:03
  • Hallo UrielMhezzek,

    Ich möchte Dich bitten folgendes zu lesen und die Beiträge die Dir geholfen haben zu bewerten. Vielen Dank.

    Nutzen Sie die Bewertungsfunktionen ("Antwort" und "Hilfreich") in den MSDN Foren! Unter anderem können andere später eine Lösung schneller finden. Es ist also wünschenswert, dass die fragenden (Benutzer) die Postings anderer Beantworter bewerten.
    Hier dazu die wichtigsten Anhaltspunkte aus den
    Forenregeln und FAQs.

    Lösungsbeiträge als „Die Antwort“ markieren
    Bitte markieren Sie den Beitrag, der zur Lösung geführt hat, als "Die Antwort". Durch Bewerten eines Beitrags als "Die Antwort" können andere Teilnehmer die Lösung schneller finden. Außerdem können Sie dem Benutzer, der die Antwort eingereicht hat, für seinen Beitrag danken und zur Steigerung der Antwortqualität in der Diskussionsgruppe beitragen.
    [Quelle:
    Forenregeln]

    Bitte markiere den/die Beiträge als Antwort, die dir geholfen haben, dein Problem zu lösen. Das ist zum einen eine Anerkennung für die Autoren dieser Beiträge, zum anderen hilft es zukünftigen Lesern, sich in diesem Thread besser zu orientieren und Antworten auf ihre Fragen schneller zu identifizieren.

    Wie zeige ich an, dass meine Frage durch einen Beitrag beantwortet wurde?

    Wie bewerte ich einen Beitrag als hilfreich? Um einen Beitrag als hilfreich zu bewerten, klicken Sie in einem beliebigen Beitrag auf Als hilfreich bewerten. Sie können Ihre Stimme nur einmal für einen Beitrag abgeben.
    [Quelle:
    Häufig gestellte Fragen]

    Grüße,

    Ionut


    Freitag, 12. Oktober 2012 08:02
    Moderator
  • Hallo zusammen,

    ich habe eine Weile überlegt, ob ich mich einmische oder nicht. Aber ein paar Anmerkungen kann ich mir doch nicht verkneifen.

    @Marcel , Uriel

    Bitte keine permante Großschreibung in Beiträge. Dies gilt als Gebrüll und ist einer konstruktiven Diskussion nicht würdig.

    @Uriel

    >>Ob und wie MAN DAS EBEN MACHT kann kein externer Experte entscheiden, da er weder die Aufgabe noch das Nutzerverhalten kennt

    Das entscheidet auch kein externer Experte. Solltest Du eine App nur für dich programmieren, kannst Du es machen wie Du willst. Willst Du eine App für viele, musst Du dich an die Zertifizierungsrichtlinien halten. Da stehen Dir aber nur die von Marcel genannten Verzeichnisse zur Verfügung. Deine Lösung würde mit hoher Sicherheit so nicht zertifiziert.

    Schöne Grüße

    Oliver


    Freitag, 12. Oktober 2012 15:13
  • Also ich habe auch schon lange überlegt, ob ich diese Antwort schreiben soll oder nicht, aber irgendwann ist genug Diskutiert.

    1. Es ging von anfang an darum initialdaten der App mit zu geben, da hier eine nicht kleine Datenmenge mit geliefert wird, ohne die die App gar keine Daseinsberechtigung hat und ich nicht im Code Hard codieren will. Ich glaube auch nicht das dies eine seltene Anforderung ist.

    2. Habe ich nicht angefangen mit der Großschreibung und fand den ersten Eintrag schon sehr kritisch und habe es mir einmal gefallen lassen und danach nur darauf reagiert...

    3. Ich weiß ehrlich gesagt nicht, was an meiner Lösung so verkehrt sein soll. Ich halte mich an alle mir bekannten Zertifizierungsrichtlinien ein. Lasse den Nutzer entscheiden wo er seine Daten speichern möchte. Ich weise ihn halt nur von Anfang an darauf hin, dass durch löschen der App die Daten im "nicht dauerhaft persistenten" LocalFolder die Daten ebenfalls gelöscht sind. Es geht um Daten, die meist eh ohne die App erzeugt werden, dann in die App eingeflegt werden, irgendwann wird die App vermutlich gelöscht oder ein paar Monate bis Jahre nicht angepackt und dann wieder hervorgekramt werden, weil man doch Anfängt das Spiel (für dessen Verwaltung die App ist) zu spielen und man beachte in der ganzen Zeit werden die Daten auch nicht veralten. Es hat also einen Grund, warum ich hier eine Datenspeicherung im KnownFolder beabsichtige und diese von vornerein bevorzuge. Wenn der Nutzer dies nicht möchte, kann er immer noch auswählen, das er es nicht will.

    Ich sehe es aber auch im übrigen von einen persönlichen Stand unabhängig von der App. Wenn ich ein Spiel spiele, irgendwann aufhöre, das Spiel aus welchen Grund auch immer wieder anfange, und sei es nur, bei der App Solitär den Highscore von damals zu knacken, will ich nicht, dass das Betriebssystem entscheidet, ob meine persönlichen Daten mit gelöscht werden nur weil der Programmierer zu faul, zu eingeschüchtert durch die neue Philosophie der Rechte (immerhin bedeutet weniger Rechter zu verlangen häufig eine höhre Sicherheit für den Benutzer und damit evtl einen zusätzlichen Grund eine App zu installieren oder nicht; denn dafür ist die Rechteverwaltung da) oder einfach sich keine Gedanken darüber gemacht hat.

    4. Ich habe das Gefühl, dass der einzige Grund, weshalb dieser Thread noch lebt, ist das ich zwei Aussagen in meinen als Antwort marktieren Thread gemacht habe. Zum einen habe ich die Lösung, so von mir gewünscht gefunden, da sollte sich auch kein Moderator einmischen und sagen, das dies nicht die Lösung ist. Ich habe kein Problem über diese Dinge zu diskutieren, aber bevormunden will man sich auch nicht lassen, was man hier mMn getan hat und mir noch in keinen anderen Codingforum passiert ist.

    Ich habe, wie Marcel geschrieben hat bei den Benutzerdaten ist keiner der genannten Verzeichnisse eine gute Wahl eine Aussage getroffen, über die hier lang und breit diskutiert wird. Wobei man Benutzerdaten, jetzt in nachhinein evtl nicht ganz die korrekte Wortwahl, unterscheiden muss, in Daten die unrelevant für die dauerhafte peristens sind, wie z.B. letzte Positionsdaten der Nutzeroberfläche und co, und welche die relevant sind, wie z.b. die Bachlorarbeit des Studiums. Die Daten die ich hier nicht speichern will, sind von letzterer Natur, oder würdet ihr wollen, wenn ihr Word installiert, dass dann alle eure erstellten Dokumente vom Betriebssystem gelöscht werden, nur weil man nicht drüber nachdachte oder es nicht wußte dass dan der LocalFolder auch weg ist? Ich glaube nicht. Und genau darum ging die Diskussion am Schluss und ich wäre langsam froh, wenn man hier mal einen Schlussstrich ziehen könnte.

    Freitag, 12. Oktober 2012 15:54
  • Also wenn ich dich richtig verstanden habe, willst Du die mit deiner App produzierten Arbeitsergebnisse wegschreiben? Dann ist die ganze bisherige Diskussion Makulatur. Leider hast Du dich in deinen bisherigen Postings sehr ünglücklich ausgedrückt. Ich dachte wir reden von Benutzerdaten rund um deine App (Benutzerdefinierte Einstellungen, AddIns etc) Diese gehören in die genannten Ordner. Dokumente speichert man im  Ordner "Documents" oder wie beim neuen Office in der Cloud (SkyDrive). Die dort abgelegten Dateien werden auch  nach der Deinstallation der App nicht angerührt.

    Der Speicherort wäre also:

    StorageFolder storageFolder = KnownFolders.DocumentsLibrary;

    Schöne Grüße

    Oliver

    • Als Antwort vorgeschlagen IngoManthey Montag, 12. November 2012 10:49
    Freitag, 12. Oktober 2012 16:53
  • Hallo Oliver,

    Dann ist die ganze bisherige Diskussion Makulatur.

    Ich bin da entschieden anderer Meinung, umso mehr als KnownFolders.DocumentsLibrary etliche Mal darin erwähnt wurde. Aber lassen wir's bitte dabei bewenden.

    Gruß
    Marcel

    Samstag, 13. Oktober 2012 10:30
  • Hallo Marcel,

    Entschuldigung, wenn meine Äußerung mißverständlich ist. Ich wollte damit nur ausdrücken, das eine Fortsetzung der Diskussion überflüssig ist, da KnownFolders.DocumentLibrary offensichtlich die Antwort ist. Ansonsten weis ich was jeder geschrieben hat und das die Diskussion durch eine unpräzise Fragestellung etwas aus dem Ruder gelaufen ist, ist mir auch bewusst.

    Schönes Wochenende

    Oliver

    Samstag, 13. Oktober 2012 13:32