Ich hatte mich wegen dem Pfad nur gewundert, weil du in deinem Screenshot Tabpage_Local.jpg nur den Hauptpfad "D:\S7_Export\Bosch" stehen hattest (aber du testest sicherlich verschiedene Pfade).

Auf deinen angehängten Screenshots kann ich jetzt anhand der Daten auch nichts fehlerhaftes erkennen. Wenn es bei dir lokal funktioniert, aber nicht auf dem Produktionsrechner, dann ist dort etwas mit der Datei (oder dem Ordner) falsch.
Daher probiere mal direkt die Datei dort zu finden (mit Powershell, wie Ralf vorgeschlagen hat).

PS: Noch als Rückfrage, da du nicht direkt dazu was geschrieben hast: Ist die Performance durch das Umschreiben des Filters denn jetzt akzeptabel?

Hallo Th69,

Ja, die Performance ist ok. Das Tool braucht ca. 6 sek.
Bei 75 % stockt es ein bisschen, weil über Netzwerk kopiert wird.

Zitat:

Ich hatte mich wegen des Pfades nur gewundert,

Ja richtig, bei mir zu Hause habe ich nur mit "D:\S7_Export\Bosch" getestet.
Hier im Büro mit der langen Variante "D:\S7_Export\Bosch\CH_00_1\PRG_01".
Entspricht auch der Variante auf dem Produktionsrechner.

Ich habe mal mit PowerShell getestet. Die Datei wird gefunden. Siehe Bild.

Da muss ich weiter schauen. Ist bestimmt ein ganz banaler Fehler.

Vielen Dank, für Eure Hilfe.

Grüße Tom

Die Performance ist doch schon mal ganz gut (zumindenstens gegenüber den vorherigen 30 bzw. 40 sek.).

Bist du denn jetzt mit dem Fehler bei der Datei weitergekommen?
Wird die Datei denn überhaupt nicht ins Zielverzeichnis kopiert oder wird sie nur nicht im Quellverzeichnis gelöscht? Letzteres kann daran liegen, wenn noch ein Prozess (exklusiven) Zugriff auf diese Datei hat.
Ansonsten mal die Datei selber von Hand kopieren, dann löschen und danach wieder neu zurückkopieren (und dann, wenn keine Fehlermeldung dabei erschienen ist, dein Programm nochmals darüber laufen lassen).

Zitat:

Letzteres kann daran liegen, wenn noch ein Prozess (exklusiven) Zugriff auf diese Datei hat.

War das nicht eine der wenigen Stellen wo sowas wie Logging eingebaut war Der Faden hier ist schon so lang da kann man schonmal den Faden verlieren

Sowas wie noch gesperrt oder fehlende Zugriffsrechte auf die Datei oder den Ordner sollte doch im Log stehen.

Ich meinte bei File.Move:

Zitat:

Moving the file across disk volumes is equivalent to copying the file and deleting it from the source if the copying was successful. If you try to move a file across disk volumes and that file is in use, the file is copied to the destination, but it is not deleted from the source.

Und dann kommt aber eben keine Exception (und daher auch kein Log-Eintrag) - wobei ich nicht weiß, ob auf dem Produktionsrechner unterschiedliche Laufwerke verwendet werden (beim lokalen Testen wohl nicht).

Guten Morgen,

Vielen Dank für Eure Antworten und Sorry das ich jetzt erst Antworte.
Ich musste unerwartet auf Dienstreise in ein anderes Werk.

Nun ich habe den "Fehler" gefunden.

@ Ralf

Es hat tatsächlich an den freigegebenen Ordner gelegen.
"D:\S7_Export\Bosch\CH_00_1\PRG_01".
Ich habe die Freigabe für PRG_01 eingerichtet und danach wurde auch die letzte Datei verschoben.

@ TH69

Richtig ich habe keine Exception gehabt und somit auch keinen Log-Eintrag.
Jetzt wo alle Rechten vorhanden sind kopiert das Tool zwischen 3 und 6 sek.

Ich denke das wir hier jetzt abschließen können. Ich habe noch eine Frage auf die Zukunft bezogen.
In meiner Abwesenheit wurde unsere Windows 10 Version 1607 auf 1809 mit einem Setup hochgezogen.
Warum nur auf 1809 kann ich nicht beantworten das hat unsere IT so entschieden.
Jetzt ist natürlich kein .Net Framework 4.8 mehr vorhanden. Das muss ich jetzt nach installieren.
Kann ich das vielleicht in das Tool mit einarbeiten so das, wenn jemand das Programm startet
und es ist kein .Net 4.8 vorhanden, das als Erstes das .Net installiert wird?
Es kann ja auch in der Zukunft noch passieren das auf Windows 11 hochgerüstet wird. Nur als Beispiel.
Wenn das Tool solche Probleme gleich selbst erkennt, wäre das von Vorteil.

Oder wäre ein wechsel auf eine der Core Versionen besser?
Was aber bedeuten würde das wieder alles umgeschrieben werden muss Oder?
Ehrlich gesagt würde ich das lieber vermeiden aber ich schätze Eure professionelle Meinung.

Vielen Dank für Eure tolle Unterstützung.

Grüße Tom

Wenn man über die normalen Windows Update Mechansimen einen PC aktualisiert verschwinden die installierten Frameworks eigentlich nicht.
Das klingt eher nach mehr oder weniger neu aufgesetzt.


Das nachinstallieren des Frameworks ist tatsächlich nicht übermäßig schwer aber gehört eher in eine Setup Anwendung. Deine Anwendung kann sich nicht wirklich selbst aus diesem Sumpf ziehen. Deine Anwendung ist ja bereits in .Net geschrieben. Das Framework muß aber "vorher" da sein bevor deine Anwendung irgendwas tut.

Wenn auch eine Setup zu viel ist solltest du mal mit deiner IT Truppe sprechen. Wenn die ein Deployment Tool zum PC aufsetzen verwenden an Windows Update vorbei sollten die dann auch das 4.8 Framework mit deployen.

Servus Ralf,

Vielen Dank für deine Antwort.

Ich habe nachgefragt. Das Update von Win 10 wurde über eine Setup.exe gemacht.
Es wurde nicht neu aufgesetzt, da noch alle Programme vorhanden war.

Es liegt an der Windows 10 Version 1809. Erst mit Update vom Oktober 2018 (Version 1809) kann man 4.8 installieren.
Erst mit dem Update vom Mai 2019 wurde 4.8 mit integriert.

docs.microsoft.com/d...ies#net-framework-48

Dann werde ich das installieren müssen.

Danke

Grüße Tom