Entwickler-Ecke
Netzwerk - UWP Hintergrundsfiletransfer Lokaldir auf Windows-UNCShare
af0815 - Fr 07.07.17 09:37
Titel: UWP Hintergrundsfiletransfer Lokaldir auf Windows-UNCShare
Ich habe unter WinForms kein Problem mit dem Transfer von Dateien (jpg) vom Lokalen Dir zu einem entfernten Windows-Share als Hintergrundaufgabe.
Nur unter UW ist natürlich alles anders (IMHO) :-) Wenn ich einen Backgroundworker verwende, so gibt es bei den normalen System.IO Klassen sofort Probleme.
Die UW BackgroundUploader und BackgroundDownloader können nur mit Web-Technologien (http, ftp,..) verwendet werden, der einfache FileIO bleibt da aussen vor.
Kann mir wer einen Denkanstoß geben. Wie man unter UW solche Backgroudfiletransfers macht ? Im Unternehmensbereich kommen dieses Scenario leider öfters vor und ich habe dazu auch noch nicht wirklich Beispiele gefunden die unter UW in VS2017 wirklich arbeiten. MS bezieht die Beispiele im auf ein lokales Verzeichnis oder macht die Transfers mit http. Die UW Beispiele auf GITHub sind ausserordentlich interessant, lassen aber - scheinbar aus guten Grunde - diese Thematik IMHO vollkommen aus.
Danke
Andreas
C#-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: 47: 48: 49: 50: 51: 52:
| public void FileTimerSetup() { dispatcherFileTimer = new DispatcherTimer(); dispatcherFileTimer.Tick += dispatcherFile_Tick; dispatcherFileTimer.Interval = new TimeSpan(0, 0, 30); Debug.WriteLine("Calling dispatcherFileTimer.Start()\n"); dispatcherFileTimer.Start(); Debug.WriteLine("dispatcherFileTimer.IsEnabled = " + dispatcherFileTimer.IsEnabled + "\n"); }
public void FileTimerShutdown() { dispatcherModbusTimer.Stop(); dispatcherModbusTimer.Tick -= dispatcherFile_Tick; }
void dispatcherFile_Tick(object sender, object e) { myFileMove(); }
private void myFileMove() { string fileName = "test.txt"; string sourcePath = _captureFolder.Path; string targetPath = @"C:\Users\Public\TestFolder\SubDir"; string destFile;
if (!System.IO.Directory.Exists(targetPath)) { System.IO.Directory.CreateDirectory(targetPath); }
if (System.IO.Directory.Exists(sourcePath)) { string[] files = System.IO.Directory.GetFiles(sourcePath); foreach (string s in files) { fileName = System.IO.Path.GetFileName(s); Debug.WriteLine("Move file="+fileNmae); destFile = System.IO.Path.Combine(targetPath, fileName); System.IO.File.Copy(s, destFile, true); System.IO.File.Delete(s); } } else { Debug.WriteLine("Source path does not exist!"); } } |
af0815 - Fr 07.07.17 13:37
Hallo
und danke für den Welcome.
Direkter Aufruf:
Zitat: |
"System.InvalidOperationException: Synchronous operations should not be performed on the UI thread. Consider wrapping this method in Task.Run.\r\n at System.IO.WinRTFileSystem.EnsureBackgroundThread()\r\n at System.IO.WinRTFileSystem.DirectoryExists(String fullPath)\r\n at System.IO.Directory.Exists(String path)\r\n at QKameraVS01.MainPage.myFileMove()\r\n at QKameraVS01.MainPage.dispatcherFile_Tick(Object sender, Object e)" |
Aufruf über
C#-Quelltext
1: 2:
| var t = Task.Run(() => myFileMove()); t.Wait(); |
ergibt keinen Fehler, es werden aber auch keine Dateien - die vorhanden sind - gefunden. Das Subdir wird gefunden, das createdirectory wird ganz einfach negiert. Wenn es schon mal da war, und man löscht es, so kann es angelegt werden.
Der folgende Code läuft auch ohne Probleme, nur werden genausowenig die Dateien erkannt. Es sieht so aus als würde die $&%/% Sandbox von MS den Zugriff verweigern.
C#-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10:
| Debug.WriteLine("ButtonFile_Click " + StartDirectory + "\n"); StorageFolder myStartFolder = await StorageFolder.GetFolderFromPathAsync(StartDirectory); StorageFolder myEndFolder = await StorageFolder.GetFolderFromPathAsync(EndDirectory); StorageFileQueryResult myRes = myStartFolder.CreateFileQuery(); IReadOnlyList<StorageFile> myList = await myRes.GetFilesAsync(); foreach (StorageFile datei in myList) { Debug.WriteLine("CopyFile " + datei.Name + "\n"); await datei.MoveAsync(myEndFolder); } |
Die Bilder, um die es mir geht, kann ich Problemlos speichern, nur später aus der UW nicht mehr verschieben.
So wie es aussieht muß man mit dem Picker zuerst den Benutzer was auswählen lassen, damit man die Datei verwenden kann. Das ist ein absolutes NoGo für automatisierte Anwendungen die auf Produktionsautomaten laufen.
Die Frage erweitert sich für mich -> Kann man im Manifest oder sonstwo die nötigen Rechte setzen.
Zitat aus dem vorher geposteten Link:
Zitat: |
down vote
this is not true: Files which are opened with a file extension association or via sharing try it, by opening files from mail (outlook) or from the desktop... it simply does not work you first have to grant the rights by the file picker. so this ist sh... |
ACK
Andreas
Moderiert von Th69: Kommentare aus C#-Code entfernt.
af0815 - Fr 07.07.17 22:19
Die Deklarationen die man über VS setzen kann sind gesetzt. Das Problem ist, das ich keine Möglichkeit finde OHNE Useraktion Dateien oder Directories zugänglich zu machen. Nur genau ist der Knackpunkt, wie kann man dem System Dateien oder auch Shares bekanntgeben. An sich ist das ja sinnvoll, nur sollte man per Manifest auch definieren können. Nur dazu habe ich noch nichts brauchbares gefunden, max. Andeutungen.
Die Beispiele sollen nur zeigen, das es bei UWP noch jede Menge Fragen zum FileIO gibt.
Ja, die Filelist ist immer leer, obwohl im Verzeichnis Dateien sind.
Andreas
Delete - Sa 08.07.17 00:04
- Nachträglich durch die Entwickler-Ecke gelöscht -
af0815 - So 09.07.17 17:18
Danke, mein grundlegendes Problem ist durch die Umstellung auf einen Task
C#-Quelltext
1: 2:
| var t = Task.Run(() => myFileMove()); t.Wait(); |
erledigt worden, der Rest ist, so wie es aussieht eine Problematik die durch geänderte Rahmenbedingungen in der UWP verursacht worden. Somit ist die ursprüngliche Frage für mich erledigt und beantwortet.
Dank th69 habe ich noch einen Anknüpfungpunkt für das UWP Problem gefunden.
Andreas
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2024 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!