Der erste Blogeintrag zu Backup Service Home 4 und es geht gleich ins eingemachte: .NET Remoting.

In Backup Service Home 4 sollen alle Aktionen in einem Windows Dienst gekapselt werden, um vor allem Ressourcen zu sparen, denn das UserInterface soll nicht ständig im Hintergrund offen sein (und Backup Service Home soll endlich seinem Namen gerecht werden 😉 ). Doch wie muss die Kommunikation von Dienst und Anwendung realisiert werden? Natürlich mit .NET Remoting (ja ich weiß es gibt auch WCF).

Da .NET Remoting für mich totales Neuland ist, muss natürlich viel gelesen und ausprobiert werden. Aber nach einem langen Weg und unzähligen Stunden: es gibt noch Hoffnung. Soeben habe ich die finalen Routinen eingebaut, die die Kommunikation zwischen Dienst und Anwendung bewerkstelligen. Remote Prozeduraufruf mit Rückgabewerten, Remote Objekte mit komplexen Klassen und (das war am kompliziertesten) Ereignisse.

.NET Remoting selbst ist an sich nicht kompliziert, doch wenn man extra Wünsche hat (wie ich), dann gibt es einiges, was im verborgenen liegt. So will ich, dass die Anwendung völlig geschlossen wird, wenn keinerlei Fenster etc. angezeigt wird und wenn ich Sie wieder öffne, dann sollen bitte alle Statusinformationen weiterhin über Ereignisse live angezeigt werden. Das ist vor allem deshalb so tricky, da die Verbindung zwischen Server und Anwendung geschlossen wird und alle Remoteobjekte verloren gehen. Alles in allem funktioniert es nun tatsächlich.

Eigentlich funktionierte es schon vor ein paar Tagen, wenn nicht der Name der Eigenschaft port von TCPChannel, bei IPCChannel portName hieße. Denn das war der Auslöser für Probleme mit Ereignissen. Ich hatte immer den falschen Eigenschaftenname drin (wegen fehlender Typisierung) und deshalb wurde der Clientrückkanal zum Server nie richtig registriert.

Und noch eine Premiere feiere ich: Backup Service Home 4 wird nun in C# programmiert – für mich ebenfalls totales Neuland (auch wenn die Java-Kenntnisse den ein oder anderen Hinweis gaben).