Windows Dienst mit WCF oder Alternative

Hallo!

Ich habe eine Windows Forms Anwendung entwickelt.
Dazu möchte ich jetzt einen Windows Dienst entwickeln der mit der Windows Forms Anwendung kommunizieren und regelmäßige Aufgaben übernehmen soll.

Löst man sowas heutzutage noch mit WCF oder wir hier etwas anderes wie z.b. ASP.NET Web API empfohlen?

Vielen Dank für euren Tipp im Voraus.

Klar die API.

Für Aufgabenscheduling bietet sich aber auch Hangfire an.

Klar die API.

Dann stell ich mir die Frage warum? 🤔 =)

Geht die Frage genauer?

Geht die Frage genauer?

Ich versuchs mal: Warum "Klar die (Web)API" wenn man zwischen .NET und .NET kommunizieren möchte? Da bietet sich doch WCF mit net.tcp Binding an, wenn man keine Interopabilität braucht. Oder vielleicht msmq wenn man wirklich immer sicherstellen möchte, dass die Anfragen zur Aufgaben-Durchführung beim Service landen (auch wenns mal kurz offline ist). Oder...oder...oder.
Service-Referenz hinzufügen, Client erzeugen und Methode aufrufen; reicht fürs erste um die Füße Nass zu bekommen.
Wenn das Ziel klar Web ist (bzw. auch HTML/JS Clients und nicht WinForms), gehts zwar auch mit WCF; aber spätestens dann würde ich auch eher zur WebAPI greifen.
Ich muss an der Stelle auch zugeben, dass ich hauptsächlich mit WCF zu tun habe, weils 1. die WebAPI damals noch nicht gab und 2. aufgrund der Fachanforderungen net.tcp der geeignetste Transport ist. Web ist in meinen Applikationen kaum ein Thema, abgesehen von gelegentlichen "ich möchts aber von meinem $Tool aus ansprechen" - wofür es dann halt einen REST Endpoint mit webHttp Binding und JSON Serializer gibt, der ausgewählte Methoden anbietet.

Eine kurze generelle Erklärung warum API anstatt WCF wäre interessant gewesen...

Danke @Bhaal!

WCF hat die steilere Lernkurve. Wenn man beides noch nicht kennt, hat man mit WebAPI schneller ein funktionierendes Ergebnis. (Mit WCF hat man daegegen das bessere Ergebnis in diesem Fall. net.tcp drängt sich ja geradezu auf, da stimme ich BhaaL zu.

Kein Problem. Geht mir übrigens auch so; ich bin immer etwas skeptisch wenn jemand sagt "Nimm A statt B" ohne zu begründen warum.

Microsoft hat da auch eine recht schöne Tabelle gebastelt, wo man die beiden high-level gegenübergestellt bekommt:
WCF and ASP.NET Web API
(wo aber leider die angesprochene Lernkurve auch nicht explizit drinsteht)

Hilft vielleicht auch bei der Suche nach der geeigneten Technologie.

Wenn man weiß, dass man sich nur im .Net bewegt, dann sollte man auch wissen, dass man nicht weiß, was morgen ist, denn da kann alles wieder anders sein.

Wenn ich heute so etwas umsetzen würde, dann würde ich WebApi/SignalR statt WCF nehmen. Einfach aus dem simplen Grund, dass man bei den Clients wie auch dem Server nicht zwangsläufig an .Net gebunden bin. Ich kann, muss aber nicht.

Ich habe also wesentlich mehr Freiheiten bei der Implementierung, und das ist ein guter Grund für mich.

Hallo,

die Services sollten ohnehin technologieneutral erstellt werden. Damit meine ich dass der eigentliche Service, welcher die tatsächliche Arbeit durchführt, so entwickelt wird dass er weder von WCF noch von Web-API noch von sonst einer Kommunikationstechnologie abhängt.
Die Kommunikations-Ebene wrappt dann den eigentlichen Service (als Fassade, Adapter je nach dem wie die Ausprägung ist).

Somit ist ein Wechsel von einer Technologie zur anderen mit wenig Aufwand verbunden. Zusätzlich lässt sich der Kern-Service wesentlich besser und isolierter testen.

Ich würde bei diesen Anforderungen WCF nehmen. Und sollte es unbedingt sein müssen, dass andere Clients auch mit dem Dienst kommunizieren, so hat BhaaL einen Lösungsvorschlag gebracht, od. es wird einfach das "Frontend" gewechselt -- der Kern-Service bleibt davon unberührt, falls es wie oben erwähnt aufgeteilt wurde.
Sollte der Dienst auf der gleichen Maschine wie der Client laufen, so bietet sich dann auch NamedPipes-Binding an.

Die Lernkurve ist bei WCF auch nicht höher als bei Web-API -- hängt halt stark mit dem Background zusammen. Für einen Webentwickler mag der Schritt zum Web-API näher sein als zu WCF. Für jemanden der mit Asp.net (core) wenig bis nichts zu tun hat, mag die Lernkurve fürs Web-API höher sein als für WCF. Die Lernkurve sehe ich hier nicht als Entscheidungskriterium.

PS: bitte kein "WCF ist tot" Argument bringen.

mfG Gü

Die typischen WCF vs ASP.NET Vergleiche wiederhole ich mal nicht.
Das kann jeder selbst googlen und muss ich hier nicht copy-pasten.

Das Konzept von WCF ist total überholt; es stammt ja quasi vom Remoting ab.
WCF wurde vor über 10 Jahren konzipiert, als es um SOAP und Co ging.

(Fast) Alle Konzepte von WCF wurden mittlerweile in das Pipeline-Konzept, das mit OWIN seinen Start gefunden hat, migriert, sodass für die Anwendungsfälle von WCF i.d.R. ASP.NET mit entsprechender Middleware ein Nachfolger gefunden werden kann; mit Ausnahme des Long-Frame-Streamings.
Man kann in jede Applikation heute ein ASP.NET Core integrieren und mit einem HttpClient ansprechen. In 5 Zeilen Code gibt es einen funktionsfähigen Endpunkt.
Mit WCF? So undenkbar! Sehr hohe Abhängigkeiten an einen Monolith in Sachen Kommunikation und man braucht immer einen extra Client - plus entsprechend viel Code.

Ich würde auf keinen Fall WCF nehmen, da die Zukunft von WCF noch immer nicht definitiv entschieden ist; egal ob für Framework oder Core.
ASP.NET Core kann beides, WCF nicht.
Der gesamte Web- und Kommunikationsstack von .NET fokussiert sich heute sehr stark auf Schlankheit, Plattformunabhängigkeit und eben .NET Core. Da passt WCF nicht rein.

Es gibt noch keine definitive Entscheidung, ob WCF für .NET Core wirklich als Äquivalent kommen wird.
Stattdessen gibt es eben immer mehr Middleware-Implementierungen direkt für ASP.NET Core (wie zuletzt eben SOAP).

Ich sehe aufgrund der sehr komplexen Konfiguration von WCF, das in den Foren - egal ob hier oder auf Stackoverflow - einfach die meisten Fragen aufwirft, die Lernkurve doch deutlich höher; zudem mehr Codeaufwand.

Und bezüglich tot: Microsoft hat leider in der Vergangenheit immer wieder die Angewohnheit gehabt, dass Produkte nicht offiziell als tot bezeichnet werden - aber durch die Nichtpflege ihren Tod selbst finden.
Es gibt dazu auch einen entsprechenden GitHub Issue, der aber am Ende auch kein Licht ins Dunkle bringt, was die Zukunft angeht: Server side WCF #1200

Stattdessen gibt es von der Verantwortlichenseite eher:

That's not a good enough answer to justify an investment to re-write a 10
year old framework that has significant coupling to the Windows platform.
Linux alone is not good enough...

Hallo Abt,

Das Alter eines Konzept sagt ja nichts über die Güte aus. Wie würde es dann mit der Von-Neumann-Architektur ausschauen? Klar gibt es dazu auch Alternativen (z.B. Harvard-Architektur), aber deshalb ist VNA noch lange nicht überholt.
Ich könnte dazu noch mehr Beispiele aufzählen, auch welche die weniger Äpfel mit Birnen vergleichen, aber das finde ich nicht zielführend.

Wie kommst du das außerdem zur Aussage dass WCF vom Remoting abstammt? Ich sehe da keinerlei Abstammung.

Im Punkt dass WCF monolithisch ist kann ich nur zustimmen. Aber wem stört es (tatsächlich) und v.a. im Kontext einer WinForms-Anwendung?
.net Core ist zwar in einzelnen Paketen verfügbar, dennoch gibt es die .net Core Runtime (die bei Frameworkdepended Deploys Voraussetzung ist). Ist das nicht schon wieder ein Hauch eines Monolithen? Und ist es "schlank" wenn .net Core Runtime und asp.net Core Runtime-Store installiert sein müssen (außer bei self contained deployments)?

Für viele der möglichen Bindungen von WCF gibt es in asp.net Core kein Gegenstück. Aber da sehe ich die Frage anders: muss es Named Pipes sein od. reicht HTTP aus. Ich denke in den meisten Fällen wird HTTP auch reichen. Für Message Queues gibt es ja auch andere Lösungen und Möglichkeiten als jene die bei WCF dabei sind.

Wenn du mit Blick in die Zukunft von WCF abräts, wie passt hier dann WinForms/WPF rein? Das sollte dann auch tunlichst vermieden werden, da es in .net Core nur rudimentäre Prototypen für eine Ersatzlösung gibt.

Wer das Argument bringt dass WCF komplex zu konfigurieren ist, hat WCF nicht verstanden. Beispiel:

using System;
using System.ServiceModel;

class Program
{
	static void Main(string[] args)
	{
		var host = new MyServiceHost();
		host.Start();

		var client = new MyServiceClient();
		string ultimateAnswer = client.GetUltimateAnswer();
		Console.WriteLine($"Ulitmate answer is: {ultimateAnswer}");

		host.Stop();
	}
}

[ServiceContract]
public interface IAnswerService
{
	[OperationContract]
	string GetUltimateAnswer();
}

public class AnswerService : IAnswerService
{
	public string GetUltimateAnswer() => "42";
}

public class MyServiceHost
{
	private ServiceHost _serviceHost;

	public void Start()
	{
		if (_serviceHost != null) return;

		_serviceHost = new ServiceHost(typeof(AnswerService), new Uri("net.pipe://localhost/answerService"));
		_serviceHost.Open();

		Console.WriteLine("Service is running...");
	}

	public void Stop()
	{
		_serviceHost?.Close();
		_serviceHost = null;

		Console.WriteLine("Service stopped");
	}
}

public class MyServiceClient : IAnswerService
{
	private ChannelFactory<IAnswerService> _channelFactory = new ChannelFactory<IAnswerService>(
		new NetNamedPipeBinding(),
		new EndpointAddress("net.pipe://localhost/answerService"));

	public string GetUltimateAnswer()
	{
		IAnswerService proxy = _channelFactory.CreateChannel();
		return proxy.GetUltimateAnswer();
	}
}

Ist ein funktionsfähiger WCF-Server und WCF-Client. Wenige Zeilen Code reichen. Keine aufwändige Konfiguration ist nötig -- od. übersehe ich da etwas?

Im Vergleich zu einer HttpClient-Lösung hab ich hier sogar den Vorteil, dass Client mit dem Proxy die Schnittstellen-Methoden aufrufen kann -- ich finde das transparent. Für die Testbarkeit des Codes, der den WCF-Client verwendet, ist das auch praktisch, da ein Interface leicht gemockt werden kann.

Es mag sein dass WCF viele Fragen aufwirft, aber da geht es mehr als oft um fehlende Grundlagen.
Wenn es natürlich Anforderungen abseits der simplen Beispiele (wie oben im Code) sind wie Routing, Inspektoren, etc., so kann WCF durchaus kompliziert werden. Ich schätze aber dass dies nicht den Großteil der Anforderungen ausmacht.

Ich denke deine Sicht auf WCF ist sehr durch die Web-/Cloud-/asp.net-Core-Brille getrübt und beeinflusst. Teilweise sind die Argumente schlicht weg falsch (Aufwand, ...).
Du hast jedoch im Punkt dass asp.net Core eine mehr als gute Alternative und sicher zukunftsträchtiger ist absolut recht.
Ich will asp.net Core keineswegs schlecht reden, gefällt mir ja sehr gut (und besser als das bisherige asp.net (mvc)). Aber destwegen will auch nicht WCF Schlechtreden. Es ist ein Hilfsmittel um Anforderungen zu erfüllen. Und falls SW ordentlich modularisiert wird, so kann der Kommunikations-Teil ja einfach getauscht werden. Wer weiß schon ob Endpunkte in 10 Jahren noch HTTP-basiert kommunizieren? Od. asp.net in 10 Jahren eine weitere Reinkarnation durchführt?

mfG Gü

Bei Remoting hat man viel via Marshaling machen müssen, zB Basisklassen von MarshalByRefObject abstammen lassen.
WCF hatte unter anderem das Ziel, dies zu vereinfachen, wofür die Contract-Attribute verwendet werden. Ziel: vereinfachtung durch abstrakteres Vorgehen.
Eine Verwandschaft ist hier definitiv vorhanden.

Ja, nicht alle Arten einer Kommunikation sind in ASP.NET verfügbar; aber es gibt sehr einfachen Ersatz - außer das Bi-direktionales Streaming.

Mit WinForms und WPF ist das überhaupt nicht vergleichbar, da es sich hier um visuelle Technologien handelt, die so immer eine Abhängigkeit haben.
Bei der Kommunikationsebene sehe ich das ganz anders: hier sollte eine möglichst unabhängige Art und Weise, bei der Kommunikation, der Protokolle und dem Inhalt gewählt werden, um eine höhere Kompatibilität und Zukunftsicherheit zu gewähren.

Ich halte Deinen Code für viel zu einfach für die Realität.
Und: nein, ich hab durchaus länger Erfahrung mit WCF und durchaus auch das Verständnis einer Minimallösung der Konfiguration.
Aber da ich beide Welten sehr gut kenne (behaupte ich von mir), nehme ich mir auch raus zu sagen, dass ich WCF für die schlechtere Entscheidung (heute) halte.

Hallo Abt,

Eine Verwandschaft ist hier definitiv vorhanden.

Nein, warum auch? Bei Remoting wird die zu übetragende Klasse Teil der Klassenhierarchie von MarshalByRefObject. Bei WCF ist die zu übertragende Klasse nur mit Attribute versehen. In der Klassenhierachie kann diese eigenständig blieben bzw. exakter unter System.Object sein.
Deiner Logik folgend würde dann Web-API von WCF abstammen und folglich auch von Remoting? Das glauben wir wohl beide nicht.

Ich halte Deinen Code für viel zu einfach für die Realität.

Es kommt auf die Anforderung darauf in. Für eine einfache interne IPC mag dies ausreichen.
Deine Aussage lässt sich auf

In 5 Zeilen Code gibt es einen funktionsfähigen Endpunkt.

genauso anwenden 😉 Deshalb und wegen der aufwändigen Konfiguration wollte ich den Code zeigen. Dass dieses Snippet eher nicht für produktiven und robusten Einsatz reicht sollte klar sein.
Ein HTTP-Endpunkt lässt sich auch aufwändig konfigurieren. Alleine schon die Möglichkeiten zur Authentifizierung/Autorisierung...

visuelle Technologien handelt, die so immer eine Abhängigkeit haben.

Eine Abhängigkeit zu irgendetwas wird es wohl immer geben müssen, denn von Nichts kommt Nichts.
Aber bezogen auf visuelle Technologie und Abhängigkeit zum OS (? od. wie meintest du das) passt dieser Punkt so nicht ganz, denn auch HTML/CSS ist eine visuelle Technologie und hat keine Abhängigkeit in diesem Kontext.

Mit WinForms und WPF ist das überhaupt nicht vergleichbar

Warum nicht? WCF gibt es in .net Core nicht, daher "schlecht". WinForms und WPF gibt es in .net Core nicht, daher ...

Wenn der OT bei seinem Projekt WinForms verwendet, so ist die OS-Abhängigkeit zu Windows und .net Full ohnehin da. Und je nach Anforderung an den Kommunikations-Dienst kann das WCF od. Web-API gewählt werden.
Wobei ich WCF nehmen würde, falls dieser Dienst auch wirklich nur intern und speziell für diesen Anwendung dienen soll.
Sollte der Dienst auch anders verwendbar sein od. gar via Internet, so würde ich sicherlich auf Web-API setzen, da HTTP eben universeller einsetzbar ist.
Es hängt von den Anforderungen ab. Und somit richtet sich die Wahl des Mittels auch danach wie das Ziel schneller / besser / eleganter erreicht wird.

Für Cloud-Lösungen, Mikroservices, etc. ist WCF kaum geeignet und klar HTTP zu präferieren, da in diesem heterogenen Umfeld eine Abhängigkeit zu einer Technologie (WCF mit ihren eigenen Serialisierungsformaten, denn auch SOAP geht nicht problemfrei zu anderen Plattformen) einfach nicht passt. Aber hier geht es um Winforms und die Frage nach WCF od. einer Alternative.

nehme ich mir auch raus zu sagen

Warum solltest du das auch nicht sagen dürfen? Würden manche Aussagen auch begründet und nicht einfach "Klar die API." darstellen, so nehme ich mir heraus zu sagen dass ich das besser finden würde.

Ich denke nicht dass wir in dieser Diskussion zu einem Schluss kommen werden und können. Hoffentlich haben wir den OT nicht ganz verwirrt und er verwendet jetzt Remoting 😉

mfG Gü