Entstehung

In meinem letzten Artikel habe ich beschrieben, welche unterschiedlichen Möglichkeiten es zur Inter-Process-Communication zwischen einer GUI und einem Windows-Service gibt. Für unsere Magento-Schnittstelle, die ebenfalls als Windows-Dienst im Hintergrund arbeitet, wollten wir eine einfache Möglichkeit schaffen um auch über das Netzwerk oder sogar eine Internetverbindung den Dienst kontrollieren und steuern zu können. Dazu haben wir uns letztendlich für den Einatz von WCF (Windows-Communication-Foundation) entschieden. Etwas verspätet aber doch, halte ich damit mein Versprechen und präsentiere unsere Lösung und auch etwas Beispielcode.

Systemaufbau

Wir haben einen Windows-Dienst, der im Hintergrund irgendeine lange Aufgabe ausführt und dabei Statusmeldungen via WCF an einen oder mehrere Frontends schickt. Der Dienst läuf mit .NET 4 und hostet einen WCF-Service, der einen Endpunkt über ein NamedPipe-Binding zur Verfügung stellt. Der Frontend ist eine relativ überschaubare WPF-Anwendung, der den WCF-Service konsumiert (=Client) und auch einen Callback-Kontrakt implementiert, damit der Dienst (=Server) jederzeit Nachrichten an den oder die Clients schicken kann. Hier eine schematische Darstellung:

Der Windows-Dienst

Zunächst einmal erstellen wir einen Windows-Dienst, der im Sekunden-Takt irgendeine Aufgabe ausführt und dabei eine Nachricht in die Event-Log schreibt. Wie man grundsätzlich einen Windows-Dienst in C#/.NET erstellt kann man zur Auffrischung hier nachlesen. Interessanter wird es in der OnStart-Methode. Hier starten wir einen neuen Thread, der für die regelmäßige Ausführung der Aufgabe zuständig ist (deshalb auch schedulerThread):

        protected override void OnStart(string[] args)
        {
            ...

            // start scheduler-thread
            SchedulerThread = new Thread(this.ScheduleHandler);
            SchedulerThread.Start();
        }

Hier die Methode des neuen Threads, die dann pro Sekunde einen Tick in die EventLog schreibt (vorerst):

        private void ScheduleHandler()
        {
            while (true)
            {
                var beginTime = DateTime.UtcNow;

                try
                {
                    EventLog.WriteEntry(EventLogSource, "Tick", EventLogEntryType.Information);
                }
                catch (Exception ex)
                {
                    EventLog.WriteEntry(EventLogSource, "Error: " + ex.Message, EventLogEntryType.Error);
                }

                // wait until next processing-cycle
                var duration = DateTime.UtcNow - beginTime;
                int milisecondsToWait = (1000) - (int)duration.TotalMilliseconds;
                if (milisecondsToWait > 0)
                    Thread.Sleep(milisecondsToWait);
            }
        }

Zu guter letzt noch die killer-Methode, die den Thread wieder beendet, wenn der Windows-Dienst gestoppt wird:

        protected override void OnStop()
        {
            // stop scheduler-thread
            killThread(SchedulerThread);
        }

        private void killThread(Thread threadToKill)
        {
            if (threadToKill != null && threadToKill.IsAlive)
            {
                // interrupt the thread so it has the opportunity to clean up
                threadToKill.Interrupt();

                // wait one seconds for the thread to finish
                threadToKill.Join(1000);

                // if the thread is still alive, kill it
                if (threadToKill.IsAlive)
                    threadToKill.Abort();
            }
        }

Hosten des WCF Service

Bis jetzt haben wir nur einen “normalen” Windows-Dienst, der pro Sekunde einen Tick in die Ereignisanzeige schreibt. Damit sich aber später unsere Frontend-Anwendung mit dem Dienst verbinden kann, hosten wir einen WCF Service innerhalb des Windows-Dienstes. In diesem Beispiel verwenden wir einen NamedPipe-Endpunkt, der sich für eine besonders schnelle Kommunikation auf demselben Computer eignet. Natürlich könnten wir hier aber auch ein TcpBinding oder ein WsDualHttpBinding verwenden, wenn die Kommunikation über das Netzwerk stattfinden soll. Wichtig ist hier nur, dass es sich um ein Duplex-kompatibles Binding handelt, damit wir über die WCF-Callbacks auch Nachrichten vom Server an den Client pushen können.

Das Hosten eines WCF-Services innerhalb eines Windows-Dienstes ist mihtilfe der ServiceHost-Klasse recht einfach. In unserem Beispiel verzichten wir zur Gänze auf eine Konfiguration über die app.config, sondern erstellen den ServiceHost programmatisch. Hier die finale OnStart und OnStop-Methode.

        protected override void OnStart(string[] args)
        {
            /////////////////////////////
            // wcf-service host

            controlServiceHost = new ServiceHost(typeof(ControlService), new Uri[] { new Uri("net.pipe://localhost/servicecontrol") });
            controlServiceHost.AddServiceEndpoint(typeof(IControlService), new NetNamedPipeBinding(), "");

            // add metadata-binding, so that a proxy can be generated for the client (not recommended for production-use!)
            var serviceMetadataBehaviour = new System.ServiceModel.Description.ServiceMetadataBehavior();
            controlServiceHost.Description.Behaviors.Add(serviceMetadataBehaviour);
            controlServiceHost.AddServiceEndpoint(ServiceMetadataBehavior.MexContractName, MetadataExchangeBindings.CreateMexNamedPipeBinding(), "mex");

            // start wcf-service
            controlServiceHost.Open();

            // start scheduler-thread
            SchedulerThread = new Thread(this.ScheduleHandler);
            SchedulerThread.Start();
        }

        protected override void OnStop()
        {
            // stop wcf-service
            controlServiceHost.Close();

            // stop scheduler-thread
            killThread(SchedulerThread);
        }

Beim Starten des Windows-Dienstes wird somit ein WCF-Endpunkt mit der Adresse “net.pipe://localhost/servicecontrol” erstellt. Zusätzlich erstellen wir auch noch einen Metadata-Endpunkt, damit uns Visual Studio im Client-Projekt schnell und einfach einen Service-Proxy erstellen kann.

Bevor ich jetzt zeige, wie die Klasse ServiceControl, also die Implementierung unseres WCF-Services aussieht, ersetzen wir in der ScheduleHandler – Methode (siehe weiter oben) das Schreiben in die Eventlog, durch einen Aufruf unseres WCF-Services (Singleton!), der eine Nachricht (z.B. eine Statusmeldung) an alle Clients veröffentlicht:

//EventLog.WriteEntry(EventLogSource, "Tick", EventLogEntryType.Information);
ControlService.CurrentInstance.PublishMessage("Tick");

WCF Duplex Service

Jetzt kommt der spannendere Teil… für die 2-Wege-Kommunikation brauchen wir einen sogenannten Duplex-Service, bei dem nicht nur der Client, sondern auch der Server eine Nachricht an den jeweils anderen schicken kann. Damit wird eigentlich ein Nachrichten-Pushing gemacht, d.h. der Server schickt immer dann – und nur dann – wenn er eine neue Nachricht hat, diese zu den Clients. Die schlechtere Alternative wäre hier einen normalen WCF-Dienst zu erstellen, wo der Client in einem kurzen Intervall pollt und den Server dabei nach neuen Nachrichten abfragt. Schlechter ist diese Variante deshalb, weil durch das ständige Aufrufen des Dienstes von dem Client unnötiger Overhead (Traffic) entsteht. Außerdem kommen die Nachrichten bei längeren polling-Intervallen (zugunsten eines verringerten Overheads) nur zeitverzögert am Client an.

Für die Umsetzung der Duplex-Kommunikation, bietet uns WCF das Konzept von Callback-Methoden, also Methoden, die vom Server aus auf dem Client aufgerufen werden. Damit der Server aber die entsprechenden Methoden am Client aufrufen kann um Nachrichten an diesen pushen, muss zunächst der Client eine Verbindung zum Server aufbauen und sich “subscriben”. Der Server speichert dann den CallbackChannel (also die Verbindung zum Client) in einer Liste ab, und kann dann bei Bedarf an alle Clients die Nachrichten schicken.

Aber erstmal langsam, hier die Interfaces für den Service-Contract:

    [ServiceContract(CallbackContract = typeof(IControlServiceCallback))]
    public interface IControlService
    {
        [OperationContract]
        void Subscribe();

        [OperationContract]
        void Unsubscribe();
    }

    public interface IControlServiceCallback
    {
        [OperationContract(IsOneWay = true, AsyncPattern = true)]
        IAsyncResult BeginOnMessageReceived(string message, AsyncCallback acb, object state);
        void EndOnMessageReceived(IAsyncResult iar);
    }

Das IControlService unterscheidet sich hier von einem “normalen” WCF-Service nur dadurch, dass wir auch gleich einen CallbackContract definieren. Im IControlServiceCallback definieren wir nur eine einzige Methode, die der Client implementierung muss. Diese ist hier asynchron ausgeführt und teilt sich somit in eine “Begin…” und eine “End…” – Methode. Der Grund warum hier eine asynchrone anstelle einer “normalen” Methode verwendet wird ist, dass dadurch der Server selbst die Callback-Methoden der Clients ansynchron ausführt. Das ist wichtig, denn wenn mehrere Clients verbunden sind, und der Server eine Nachricht an alle innerhalb einer Schleife “pusht”, dann würde ein einzelner Client mit einer fehlerhaften Verbindung den Aufruf an die nachfolgenden Clients verzögern (bis zum timeout, und das kann lang eingestellt sein!).

Als nächstes müssen wir das IControlService Interface am Server implementieren (IControlServiceCallback dann erst am Client). Hier einmal der ganze Code – Erklärungen dazu kommen darunter:

    [ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
    public class ControlService : IControlService
    {
        // returns the singleton-instance
        public static ControlService CurrentInstance { get; private set; }

        // holds the channels to all currently connected callbacks (=clients)
        private volatile IDictionary<string, IControlServiceCallback> connectedClients;

        // lock-object to synchronize between multiple concurrent threads
        private object syncRoot;

        public ControlService()
        {
            if (CurrentInstance != null)
                throw new Exception("This service-class is intended to be instatiated only once!");
            CurrentInstance = this;

            syncRoot = new object();
            connectedClients = new Dictionary<string, IControlServiceCallback>();
        }

        public void Subscribe()
        {
            // get the callback-channel to the client that called this method
            var callbackChannel = OperationContext.Current.GetCallbackChannel<IControlServiceCallback>();
            string sessionId = OperationContext.Current.Channel.SessionId;

            // store it for later use (to push messages)
            lock (syncRoot)
            {
                // make sure, that we don't add the same session twice (e.g. the client tries to subscribe multiple times)
                if (!connectedClients.ContainsKey(sessionId))
                {
                    connectedClients.Add(sessionId, callbackChannel);

                    // register for error-events of the current channel
                    OperationContext.Current.Channel.Closing += new EventHandler(Channel_Closing);
                    OperationContext.Current.Channel.Faulted += new EventHandler(Channel_Faulted);
                }
            }
        }

        public void Unsubscribe()
        {
            DisconnectClient(OperationContext.Current.Channel.SessionId);
        }

        void Channel_Faulted(object sender, EventArgs e)
        {
            var channel = sender as IContextChannel;
            if (channel != null)
                DisconnectClient(channel.SessionId);
        }

        void Channel_Closing(object sender, EventArgs e)
        {
            var channel = sender as IContextChannel;
            if (channel != null)
                DisconnectClient(channel.SessionId);
        }

        private void DisconnectClient(string sessionId)
        {
            // remove the session
            lock (syncRoot)
            {
                if (connectedClients.ContainsKey(sessionId))
                {
                    connectedClients.Remove(sessionId);
                }
            }
        }

        public void PublishMessage(string message)
        {
            lock (syncRoot)
            {
                // iterate through all connected clients and push message to each of them
                foreach (var callbackChannel in connectedClients.Values)
                {
                    // call the callback-method asynchronously, so that a leaking connection to one of the clients does not affect this loop
                    var asyncResult = callbackChannel.BeginOnMessageReceived(message, new AsyncCallback(OnPushMessageComplete), callbackChannel);
                    if (asyncResult.CompletedSynchronously)
                        CompletePushMessage(asyncResult);
                }
            }
        }

        void OnPushMessageComplete(IAsyncResult asyncResult)
        {
            CompletePushMessage(asyncResult);
        }

        void CompletePushMessage(IAsyncResult asyncResult)
        {
            var callbackChannel = (IControlServiceCallback)asyncResult.AsyncState;
            try
            {
                callbackChannel.EndOnMessageReceived(asyncResult);
            }
            catch { }
        }

    }

Ganz wichtiges Detail gleich zu Beginn ist folgendes:

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]

Durch die Verwendung dieses InstanceContextMode erzwingen wir, dass das Service als Singleton ausgeführt, also nur ein einziges mal instantiiert wird. Das ist wichtig, denn in einem privaten Feld speichern wir die Liste der verbundenen Clients mit deren SessionId ab, die wir PublishMessage – Methode brauchen um die Callbacks der verbundenen Clients aufzurufen. Der Rest des Codes sollte selbsterklärend sein, bzw. aus den Kommentaren deutlich werden. Einzig dem lock(syncRoot) kommt noch eine besondere Bedeutung zu – Wir verwenden dieses um sicherzustellen, dass mehrere Threads nicht gleichzeitig das Dictionary der Clients verwenden. Zwar sind alle Collections des .NET – Frameworks an sich schon thread-safe, jedoch könnte es ohne dem expliziten locken zu Probleme kommen, wenn ein Thread gereade die foreach-Schleife beim Pushen durchläuft und gleichzeitig dem Dictionary hinzugefügt oder entfernt wird indem sich Clients an- oder abmelden.

WPF Clientanwendung / Benutzeroberfläche für den Dienst

Den Frontend habe ich in diesem Beispiel recht einfach gehalten. Er beinhaltet aber dennoch die wichtigsten Funktionen und sollte für seinen Zweck ausreichend sein:

In der Textbox werden Zeile für Zeile die eingehenden Nachrichten vom Server angezeigt. Die Nachrichten werden aber erst empfangen, wenn der Client am Server (am Windows-Dienst) “angemeldet” ist.

Für die Umsetzung habe ich in diesem Beispiel WPF verwendet. In einem neuen WPF-Projekt müssen wir dazu zunächst eine ServiceReference hinzufügen und können dabei die Adresse “net.pipe://localhost” verwenden. Visual Studio erkennt dann automatisch den Metadata-Endpunkt des laufenden Dienstes (vorher bitte installieren und starten!) und generiert einen entsprechenden Proxy. Hier der Code-Behind des MainWindows:

    public partial class MainWindow : Window
    {
        private ControlServiceClient controlService;

        public MainWindow()
        {
            InitializeComponent();

            // register event-handler
            this.btnSubschribe.Click += new RoutedEventHandler(btnSubschribe_Click);
            this.btnUnsubscribe.Click += new RoutedEventHandler(btnUnsubscribe_Click);

            // intialize callback
            var callback = new ControlServiceHandler();
            callback.OnMessageReceivedEvent += new ControlServiceHandler.MessageReceivedHandler(callback_OnMessageReceivedEvent);
            var callbackInstanceContext = new InstanceContext(callback);

            // create wcf-proxy
            controlService = new ControlServiceClient(callbackInstanceContext);
        }

        void btnSubschribe_Click(object sender, RoutedEventArgs e)
        {
            // subscribe to receive messages from the wcf-service
            controlService.Subscribe();
        }

        void btnUnsubscribe_Click(object sender, RoutedEventArgs e)
        {
            // unsubscribe from wcf-service
            controlService.Unsubscribe();
        }

        void callback_OnMessageReceivedEvent(string message)
        {
            Dispatcher.BeginInvoke((Action) (() =>
                {
                    tbLog.AppendText(DateTime.Now.ToLongTimeString() + " " + message + Environment.NewLine);
                    tbLog.ScrollToEnd();
                }));
        }
    }

    [CallbackBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant, UseSynchronizationContext = false)]
    public class ControlServiceHandler : IControlServiceCallback
    {
        public delegate void MessageReceivedHandler(string message);
        public event MessageReceivedHandler OnMessageReceivedEvent;

        public void OnMessageReceived(string message)
        {
            if (this.OnMessageReceivedEvent != null)
                this.OnMessageReceivedEvent(message);
        }
    }

Interessant ist hier nur die Klasse ControlServiceHandler, die den CallbackContract des WCF-Service implementiert und somit die vom Server kommenden Nachrichten empfängt, sobald via Subscribe am Server angemeldet wurde. Hier sieht man auch schon, dass bei der Generierung des IControlServiceCallback am Client nur mehr eine Methode OnMessageReceived da ist, während im selben Interface am Server durch das AsyncPattern noch die beiden Methoden BeginOnMessageReceived und EndMessageReceived definiert wurden.

Ganz wichtig ist hier, dass ConcurrencyMode.Reentrant verwendet wird, und der WPF-eigene SynchronizationContext deaktiviert wurde! Letzterer ist der Grund für unzählige Posting auf StackOverflow, bei denen über “hängende” Benutzeroberflächen geklagt wird. Grund dafür ist, dass die Callback-Methode am Client in einem eigenen Thread ausgeführt wird und man die UI bekanntlich nur im UI-Thread ändern darf. Um dieses Problem zu vereinfachen hätte WPF diesen SynchronizationContext eingeführt um dem Programmierer den manuellen BeginInvoke-Aufruf zu ersparen, nur leider funktioniert der in vielen Situation nicht ordentlich. Deshalb verlassen wir uns hier besser auf die bekannten Methoden und verwenden im Event-Handler der MainWindow-Klasse Dispatcher.BeginInvoke um den WCF-Thread mit dem UI-Thread zu synchronisieren.

So, das war’s auch schon. Wir haben jetzt einen Windows-Dienst geschaffen und einen WPF-Client entwickelt, der die Nachrichten des Windows-Service empfängt und anzeigt. Das Beispielprogramm kann einfach erweitert werden, sodass der Client auch Befehle an den Dienst schicken kann oder z.B. auch über ein NetTcpBinding die Ausführung von mehreren Clients auf unterschiedlichen Computern im Netzwerk zulässt.

Den vollständigen Code zum Projekt gibt es hier zum Herunterladen.

Ich hoffe mit diesem Beitrag dem einen oder anderen helfen zu können, und freue mich über Verbesserungsvorschläge und Tipps wie man meinen Code optimieren könnte!

Hintergrund

Bei einem aktuellen Projekt verwenden wir einen Windows Service um im Hintergrund Daten zwischen einem Warenwirtschaftssystem und Magento zu synchronisieren. Dieser Vorgang wird in einem Intervall von 10 Minuten automatisch ausgeführt. Während einer Synchronisation werden hunderte Log-Meldungen erzeugt, die vom Dienst zunächst zwischengespeichert und am Ende der Synchronisation zusammengefasst in die EventLog geschrieben werden. Nachteil dabei ist, dass man während einer Synchronisation nicht live verfolgen kann, was der Dienst gerade macht und erst am Ende die fertige Rechnung präsentiert bekommt. Gleichzeitig soll es zukünftig auch möglich sein, einfache Befehle an den Dienst zu schicken, um etwa damit eine Synchronisation manuell anzustoßen oder den Cache zu leeren.

Anforderungen

Ziel ist es, eine WPF-Anwendung zu erstellen die in einem Textfenster die einzelnen Log-Meldungen “live” anzeigt und gleichzeitig eine einfache Steuerung des Dienstes ermöglicht. Für unseren Anwendungsfall ist es ausreichend, dass die Anwendung lokal auf der selben Maschine läuft, auf der auch der Windows-Dienst installiert ist. Für zukünftige Weiterentwicklungen wäre es allerdings wünschenswert, wenn die Anwendung auch von einem anderen PC aus ausgeführt werden kann. Die Performance der Applikation spielt dabei keine Rolle, das heisst auch mehrere Sekunden Zeitverzögerung bis zur Anzeige der Log-Meldungen sind tolerierbar.

Recherche

Zu Beginn habe ich gedacht, dass diese Aufgabe ziemlich trivial sei, besonders auch deshalb weil ich zig verschiedene Anwendungen kenne und verwende, die genau das selbe machen. Ich hatte angenommen, Microsoft hätte uns sicherlich schon ein fertiges Konzept bzw. ein einfach zu nutzendes Framework für genau eben diese Anforderung zur Verfügung gestellt. Stattdessen gibt es eine Fülle unterschiedlichster Möglichkeiten und Technologien um Inter-Process-Communication zwischen dem Windows-Dienst und WPF-Anwendung zu implementieren. Auch in den spärlichen Foren-Beiträgen und Blogs gehen die Meinungen zu diesen Varianten weit auseinander. Ist für einige WCF die erste Wahl, so geht für andere nichts über Named Pipes über ein eigenes Protokoll/Kontrakt.

Nachdem sich die Recherche für mich sehr mühsam und langwierig gestaltet hat, versuche ich mit diesem Artikel die Lücke zu schließen, und einen Überblick über die verschiedenen Möglichkeiten zu geben. In einem weiteren Artikel werde ich dann näher auf die Umsetzung mit einer der vorgestellten Methoden eingehen. Bitte verzeiht mir, dass ich die Pros und Kontras nach unseren eigenen Anforderungen erstellt habe und daher für diese keinen Anspruch an allgemeingültige Objektivität erhebe.

Auf folgende Möglichkeiten werde ich kurz eingehen:

• Microsoft Message Queuing (MSMQ)
• Shared Memory
• Named Pipes
• Remoting
• WCF
• Logfiles

Microsoft Message Queuing (MSMQ)

MSMQ ist ein Service-Bus und ermöglicht IPC zwischen unterschiedlichen Anwendungen auch über Systemgrenzen hinweg. MSMQ wird dabei als eigener Dienst ausgeführt und bietet den Teilnehmern die Möglichkeit asynchron Nachrichten zu senden und empfangen. Das Protokoll ist grundsätzlich – ähnlich wie das Versenden einer E-Mail – für die Einwegkommunikation konzipiert (entsprechende Kontrakte auf Applikationsebene können natürlich selbst erstellt werden). Es gilt als sehr robust und zuverlässig und eignet sich daher auch für komplexe Enterprise-Systeme. Obwohl es bei Windows 7 standardmäßig mitgeliefert wird, ist eine manuelle Installation des Features notwendig.

• Nachrichten gehen nicht verloren auch wenn kein Client verbunden ist
• Sehr zuverlässig und robust
• Grundsätzlich ein OneWay-Konzept, obwohl man Duplex-Kommunikation “bauen” kann (siehe hier)
• Manuelle Installation des Dienstes notwendig

Shared Memory

Das Prinzip hinter Shared Memory ist im Grunde ziemlich simpel – zwei Prozesse teilen sich einen gemeinsamen Speicherbereich. In diesem Speicherbereich können dann sowohl der Windows-Dienst als auch die GUI-Applikation lesen und schreiben, wobei mit entsprechenden Locks darauf zu achten ist, dass nicht gleichzeitig darauf zugegriffen wird. Dank eines Posts im dotnet-forum bin ich auf den Blog von Klaus Bock aufmerksam geworden, der beschreibt wie man Shared Memory in verwaltetem Code verwendet. Seit .NET 4 hat sich der dafür notwendige Code dramatisch reduziert, und MemoryMappedFiles werden jetzt standardmäßig vom Framework unterstützt.

• Extrem schnelle Kommunikation
• Seit .NET 4 relativ einfach zu verwenden
• Kontrakt zur Duplex-Kommunikation muss auf Applikationsebene erstellt werden
• Funktioniert nur auf demselben System

Named Pipes

Eine NamedPipe ist ein “Kanal” zur Kommunikation zwischen zwei Prozessen auf demselben System war noch vor wenigen Jahren die Standardtechnik um zwischen Service und GUI zu kommunizieren. Obwohl es grundsätzlich ein Server-Client-Prinzip ist, kann – sobald der Kanal aufgebaut ist – eine Kommunikation in beide Richtungen stattfinden, ähnlich dem TcpServer und TcpClient unter .NET. So wie bei der SharedMemory-Methode muss aber auch hier der Duplex-Kontrakt auf Applikationsebene selbst gebaut werden. Hier ist das Prinzip besser erklärt.

• Seit .NET 3.5 sehr einfach zu verwenden (siehe hier)
• Sehr schnelle Kommunikation
• Kontrakt zur Duplex-Kommunikation muss auf Applikationsebene erstellt werden
• Funktioniert nur auf demselben System

.NET Remoting

Remoting war unter .NET die bevorzugte Technologie um über Systemgrenzen hinweg zwischen zwei Prozessen zu kommunizieren. Die Funktionsweise ist dabei ähnlich dem eines Webservice, d.h. die Daten werden serialisiert und per XML übermittelt. Beide Seiten müssen dabei .NET verwenden und jeweils eine Kopie einer “geteilten” Klassenbibliothek haben, die das sogenannte RemoteObject beinhaltet. Letzteres ist eine Klasse die von MarshalByRefObject ableiten muss und dann zur Kommunikation verwendet wird. Das Framework erstellt dabei für die Applikation intransparent die Proxy-Klasse, sodass das RemoteObject in der Consumer-Applikation (hier die GUI-Anwendung) wie ein lokales Objekt verwendet werden kann. Remoting wurde mit dem .NET Framework 3.0 durch WCF abgelöst und wird zwar weiterhin unterstützt, jedoch nicht mehr von Microsoft empfohlen und weiterentwickelt.

• Einfach zu implementieren
• Einfache Duplex-Kommunikation (über Rückgabewerte von Methoden)
• Kann sowohl auf TCP-Ebene als auch über Http betrieben werden (Endpunkte können über das Internet verbunden werden)
• Von Microsoft nicht mehr empfohlen / weiterentwickelt
• Eng gekoppelte objektorientierte Architektur (keine SOA, beide Anwendung teilen sich eine Klasse oder ein Interface)

Windows Communication Framework (WCF)

WCF ist seit Version 3.0 Bestandteil des .NET Frameworks und ist als allgemeines Framework zur Kommunikation zwischen verschiedenen Endpunkten gedacht. Durch das Konzept der Bindings ist es möglich mehrere Transportwege gleichzeitig zur Verfügung zu stellen (Webservice-Binding, NamedPipe-Binding, binäres Binding über Tcp, etc.). Für alle relevanten Transportwegen (lokal und über http) sind Bindings mit Duplex-Kontrakten verfügbar, sodass über das Konzept der Callback-Funktionen eine einfachste Zwei-Wege-Kommunikation möglich ist.

• Bevorzugtes Framework von Microsoft (daher zukunftssicher)
• Einfache TwoWay-Kommunikation
• Verschiedene Bindings möglich (z.B. lokal über TCP; WAN über http)
• Etwas geringere Performance gegenüber SharedMemory (für uns nicht relevant)

Logfiles

Der Vollständigkeit halber, möchte ich auch auf die wahrscheinlich simpelste Variante eingehen – die Kommunikation über Textdateien. Die Idee dahinter ist, dass der Service seine Logmeldungen in eine Textdatei einzeln hinzufügt und gleichzeitig die GUI-Anwendung in einem kurzen Intervall die Datei liest und dessen Inhalt parst. Sogar der Rückweg ließe sich über eine zweite Textdatei in umgekehrter Reihenfolge realisieren. In der Praxis stellt diese Methode allerdings für uns keine echte Alternative dar.

• Extrem einfach zu implementieren
• Schlechte performance durch große Anzahl an IO-Operationen
• Fehleranfällig (es muss sichergestellt werden, dass die Datei direkt nach dem Schreiben wieder geschlossen wird, damit sich die Prozesse nicht gegenseitig blockieren)
• usw.

Fazit

Nachdem ich nun alle möglichen Varianten auf dem Tisch hatte fiel die Entscheidung recht eindeutig auf WCF. Einerseits haben wir bereits einiges an Erfahrung mit WCF / Webservices und auch bei einem Projekt bereits einen Duplex-Contract mit einem NetTcpBinding eingesetzt, andererseits hat man mit WCF ein sehr stabiles und robutes Framework und muss sich um keine low-level-Details wie bei SharedMemory oder NamedPipes kümmern.

In den nächsten Tagen werde ich hier in einem weiteren Artikel beschreiben, wie wir schließlich die Kommunikation zwischen Service und GUI-Anwendung mit WCF realisiert haben und auch etwas Beispielcode liefern.

Szenario

Für unsere Firmenwebseite verwenden wir das CMS-System Sitefinity auf Basis von ASP.NET 3.5. Im Moment bin ich dabei ein Unterverzeichnis /produkte zu erstellen, das wir zukünftig verwenden möchten um einige Tools und Anwendungen online zu verkaufen. Aus unterschiedlichsten Gründen haben wir uns für den Einsatz von ASP.NET MVC 3 mit der Razor-ViewEngine entschieden. Selbstverständlich läuft das Ganze mit ASP.NET 4. Im Grunde genommen eine einfache Aufgabe würde man meinen – im IIS-Manager eine virtuellen Anwendung hinzufügen, einen Anwendungspool mit v4.0 zuweisen und fertig. Die Ernüchterung kam dann gleich beim ersten Versuch die Anwendung in der Testumgebung zu starten:

Der “system.web.extensions/scripting/scriptResourceHandler”-Abschnitt wurde doppelt definiert.

“Doppelt definiert” ist einfach verständlich war mein Gedanke… nur leider ließ sich der beklagte Abschnitt nirgendswo in der web.config der Child Application finden. Nach kurzer Denkpause kam mir aber dann die Erinnerung an die machine.config, die sich irgendwo im Installationsverzeichnis vom .NET Framework befinden müsste und von der alle web.configs implizit erben. Eine kurze Google-Suche hat mir dann auch den genauen Pfad verraten: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config. Als gelernte ASP.NETler wissen wir, dass diese config als “Basis” für alle web.configs verwendet wird und am Ende eine einzige “verschmelzte” Konfigurationsdatei herauskommt die dann von der Runtime verwendet wird. Und tatsächlich – in dieser machine.config fand sich eine Zeile <section name=”scriptResourceHandler”… somit hatte ich den doppelten Eintrag gefunden.

Lösung / Teil 1

Nun da ich das Problem kann, versuchte die ersten spärlichen Tipps aus dem Internet zu verwerten. Diese gingen von einem <clear /> in der web.config der Child Application bis zu einem <location path=”.”> in der config der Hauptseite – alles vergebens. Irgendwann fand ich schließlich den entscheidenen Hinweis hier: ASP.NET 4 Breaking Changes
Die Lösung war dann wieder einmal einfacher als gedacht – Man nimmt den gesamten Bereich <configSections> aus der web.config der Hautpseite (ASP.NET 3.5) heraus und gibt ihn stattdessen in die globale web.config, die sich auf einem 64Bit-System hier befindet: C:\Windows\Microsoft.NET\Framework64\v2.0.50727\web.config. Diese wird also in der Hierarchie der config-Dateien beim Kompilieren der Child Application mit v4 ignoriert und man hat somit auch keinen doppelten Eintrag mehr!

Nach der anfänglichen Freude endlich dieses Problem gelöst zu haben, machte sich aber wieder die Ernüchterung breit, denn der nächste Fehler wartete schon:

The value for the ‘compilerVersion’ attribute in the provider options must be ‘v4.0′ or later if you are compiling for version 4.0 or later of the .NET Framework. To compile this Web application for version 3.5 or earlier of the .NET Framework, remove the ‘targetFramework’ attribute from the <compilation> element of the Web.config file.

Irgendwie auch wieder verständlich, denn in der web.config der Hauptseite befand sich die Zeile <providerOption name=”CompilerVersion” value=”v3.5″/>. Damit wurde der Runtime klar gemacht, dass wir die ASP.NET 3.5 wollen. Die Einstellung wird in die Child Application vererbt und dort haben wir aber ASP.NET 4. Wie kann ich also verhindern, dass diese Einstellung an die Child Application vererbt wird?

Lösung / Teil 2

Um zu verhindern, dass einzelne Einstellungen einer web.config in die Child Applications vererbt werden, kann man die betreffende Einstellung folgendermaßen verpacken:

<location path="." inheritInChildApplications="false">
  <!-- Einstellung die nicht vererbt werden soll -->
</location>

Damit bleibt diese Einstellung in der web.config und wird nicht an die Child-Application vererbt. ACHTUNG: Dieser “Trick” funktioniert nicht mit allen Elementen einer web.config – <configSections> hätten wir auf diese Art nicht verpacken können!

Nachdem ich also den gesamten Bereich <system.codedom> per <location …> davon hinderte sich zu vererben, war dieses Problem gelöst. Wie erwartet kam aber auch schon das nächste, dieses Mal ein altbekannte Fehlermeldung:

Die Datei oder Assembly “assemblyName” oder eine Abhängigkeit davon wurde nicht gefunden

Dabei beziehte sich assemblyName auf einen selbstgebauten HttpHandler, der in der Hauptseite mit ASP.NET 3.5 verwendet wurde. Natürlich war die entsprechende dll-Datei nicht im bin-Ordner der Child-Application vorhanden.

Lösung / Teil 3

Ich musste verhindern, dass auch diese Abhängigkeit von der Hauptseite zur Child Application vererbt wird. Die Vorgangsweise per interhitInChildApplications=”false” kannte ich bereits. Als danach allerdings schon die nächste Abhängigkeit Probleme verursachte hatte ich endlich den Mut, den gesamten Bereich <system.webServer> zu verpacken und konnte damit schließlich das Problem lösen:

<location path="." inheritInChildApplications="false">
  <system.webServer>
    <!-- ... -->
  </system.webServer>
</location>

Damit war sichergestellt, dass alle Einstellungen der Hauptseite auch dort bleiben und meine Child Application mit ASP.NET 4 hat endlich funktioniert!
Ich finde es immer wieder spannend, wieviel Zeit und Nerven solche scheinbar einfachen Aufgaben plötzlich verursachen können und hoffe mit diesem Beitrag auch anderen zu helfen, die vor ähnlichen Aufgaben stehen.