c#, wie reagiert ein NAS bei Exceptions die nicht abgefangen werden

[s4v]

Hallo Zusammen,

ich programmiere gerade Hobbymäßig eine Windows-Forms Anwendung für meine Arbeit. Am Ende soll diese auf unserem NAS sitzen und dort z.b. Kundenordner erstellen und XML Dokumente beschreiben und auslesen.

Woran ich aber bisher nicht gedacht habe, was passiert wenn vom Programm eine Exception hervorgerufen wird oder eine Endlosschleife die ich irgendwo vielleicht vergessen habe zu verhindern bzw abzufangen. Wie würde dann hier das NAS reagieren? Will ja nicht das unser NAS sich dann aufhängt. Da der Hauptprozess ja an sich dann auf meinem Rechner läuft, wenn ich das Programm starte, kann ich das ganz normal über den Taskmanager dann abschießen, oder?
Hat hier jemand Erfahrungswerte für mich?

 

[TorenAltair]

soll diese auf unserem NAS sitzen

Hauptprozess ja an sich dann auf meinem Rechner läuft

Was nun? Bitte genauer beschreiben, was nun wo laufen soll und was für ein NAS es ist.

 

[Der_Picknicker]

Prinzipiell ist es egal, auf welchem Gerät eine Exception läuft, du kannst die Anwendung auch auf dem NAS laufen lassen - problematisch sind Endlosschleife, die erzeugen gewöhnlich eine hohe CPU-Last. Du solltest ne Art Watchdog einbauen, damit die Anwendung nie in einen solchen Zustand gelangt, wenn der Watchdog auslöst - wird die Anwendung automatisch abgeschossen.

 

[aronlad]

Wie würde dann hier das NAS reagieren?

Wie jeder andere Rechner auch.

 

[Korben2206]

Exceptions sind abzufangen. Immer. Alles andere ist unsauber und faul.
So hat mans mir jedenfalls beigebracht. Ob das heute noch gilt, kA.

 

[s4v]

Was nun? Bitte genauer beschreiben, was nun wo laufen soll und was für ein NAS es ist.

Das Programm könnte auf dem NAS liegen, wird aber beim Ausführen ja auf dem zugreifenden Computer als Prozess ausgeführt. Alternativ kann man es natürlich auch einfach am Rechner belassen, und den Pfad zum entsprechenden Ordner auf dem NAS festlegen. Also so mein Gedanke. Es ist ein ganz simples NAS wo auf einen Freigegebenen Ordner von bestimmten PCs zugegriffen werden kann, die die Zugriffsrechte für diesen Ordner besitzen.

Prinzipiell ist es egal, auf welchem Gerät eine Exception läuft, du kannst die Anwendung auch auf dem NAS laufen lassen - problematisch sind Endlosschleife, die erzeugen gewöhnlich eine hohe CPU-Last. Du solltest ne Art Watchdog einbauen, damit die Anwendung nie in einen solchen Zustand gelangt, wenn der Watchdog auslöst - wird die Anwendung automatisch abgeschossen.

Danke dir, super Antwort, so in etwa hatte ich es erwartet, an den Watchdog hab ich gar nicht gedacht!

Ergänzung (13. März 2023)

Exceptions sind abzufangen. Immer. Alles andere ist unsauber und faul.
So hat mans mir jedenfalls beigebracht. Ob das heute noch gilt, kA.

Das ist schon klar, aber wenn man mal eine verpasst, dann lag das nicht an der Faulheit, sondern an der speziellen Exception die nie vorher auftrat

 

[Kenny [CH]]

Unhandled exception führen idr zu einem crash des service/app - was dann passiert ist dann dein code bestimmend (du hast es in der hand) oder service startup (systemd) sache

 

[mibbio]

Das Programm könnte auf dem NAS liegen, wird aber beim Ausführen ja auf dem zugreifenden Computer als Prozess ausgeführt.

Dann ist das dem NAS ziemlich egal, wenn das Programm eine Exception wirft. Das Programm läuft in dem Falle ja nicht auf dem NAS, sondern wird nur von da vor der Ausführung in den Speicher des Rechners geladen.
Das unterscheidet sich dann im Prinzip nicht von einem Programm auf einer USB-Festplatte am PC.

Theoretisch müsste das Programm nach dem Starten sogar weiterlaufen, wenn du die Verbindung zum NAS trennst und es keine zuästzlichen Daten davon lesen will.

 

[Korben2206]

Das ist schon klar, aber wenn man mal eine verpasst, dann lag das nicht an der Faulheit, sondern an der speziellen Exception die nie vorher auftrat

Dafür gibt es generische try-catch-Blöcke.. aber egal.

Das NAS wirds jedenfalls kaum kümmern wenn dein Forms-Programm abschmiert.

 

[Tornhoof]

as Programm könnte auf dem NAS liegen, wird aber beim Ausführen ja auf dem zugreifenden Computer als Prozess ausgeführt

Das geht schon länger nicht mehr gut, je nach Version von Windows und .NET. Die notwendigen Berechtigungen sind teilweise standardmäßig nicht mehr vergeben.

Daher immer lokal installieren

 

[aronlad]

Das Programm läuft in dem Falle ja nicht auf dem NAS,

Hmm also die typische serverseitige Anwendung schon.

 

[mibbio]

Es scheint ja keine serverseitig Anwendung zu sein. Windows Forms klingt mir jedenfalls sehr nach einer normalen Anwendung mit GUI.

 

[sandreas]

Es hört sich für mich an, als verwechselst du eine grafische Anwendung für den Client mit einem Dienst, der auf einem Server läuft.

Am Ende soll diese auf unserem NAS sitzen und dort z.b. Kundenordner erstellen und XML Dokumente beschreiben und auslesen.

Das hier wäre eher ein Dienst (Watchdog), der die ganze Zeit auf dem NAS "mitläuft" und sich um Wartungsaufgaben kümmert (wie z.B. das Anlegen von Verzeichnissen und verarbeiten von XML-Daten).

Warum du eine WinForms Anwendung benötigst, schreibst du z.B. gar nicht. Meiner Ansicht nach würde es ausreichen, den Dienst einfach mit einer Konfigurationsdatei zu konfigurieren und im Hintergrund auf dem NAS laufen zu lassen.

Problematisch wird es dann vielleicht, wenn du ein NAS hast, was nicht die üblichte X86/x64 Hardware hat (z.B. so ein Consumer Teil von Synology). Wenn das ein ganz normaler Windows-Server ist, ist es kein Problem, einfach einen Windows-Dienst zu schreiben, der die Aufgaben übernimmt.

Versuch mal, die Situation ein wenig anhand meiner Anmerkungen zu beschreiben:

• Was für eine Hardware bzw. Betriebssystem verwendet das NAS?
• Muss der Benutzer mit deiner WinForms Anwendung interagieren oder soll eher anhand einer Konfiguration etwas automatisch laufen und Verzeichnisse überwachen?

Im letzteren Fall könntest du dir mal diese Library anschauen: https://github.com/TestableIO/System.IO.Abstractions

Da gibt es einen Filesystem-Watcher, der dich per Event informiert, sobald sich im Dateisystem etwas ändert. Das ist sehr effizient. Den Watcher gibts zwar auch ohne Library, aber ich bevorzuge es, den Dateisystemzugriff etwas zu abstrahieren, damit man Unit-Tests schreiben kann.

c#
private void CreateWatcher() {
    var fs = new FileSystem();
    var watcher = fs.FileSystemWatcher.CreateNew();
    watcher.Path = "C:/mein/pfad";
    watcher.IncludeSubdirectories = true;
    watcher.Filter = "*.*";
    watcher.NotifyFilter = NotifyFilters.LastWrite | NotifyFilters.FileName | NotifyFilters.CreationTime |
                       NotifyFilters.DirectoryName;
    void OnWatcherDetectedChange(object sender, FileSystemEventArgs fileSystemEventArgs) =>
                    OnFileSystemChange(source, sender, fileSystemEventArgs);
    watcher.Changed += OnWatcherDetectedChange;
    watcher.Created += OnWatcherDetectedChange;
    watcher.Deleted += OnWatcherDetectedChange;
    watcher.Renamed += OnWatcherDetectedChange;
    watcher.EnableRaisingEvents = true;
}

private void OnFileSystemChange(FileSource source, object sender, FileSystemEventArgs fileSystemEventArgs) {
        Console.WriteLine("Detected filesystem change")
}