Ist .NET Remoting wirklich veraltet?


95

Alle sagen, wie .NET Remoting durch WCF ersetzt wird, aber ich frage mich, wie genau das ist. Ich habe kein offizielles Wort darüber gesehen, dass Remoting veraltet ist, und es scheint mir, dass es sicherlich Szenarien gibt, in denen Remoting sinnvoller ist als WCF. Selbst in Version 4.0 des Frameworks wurde keines der Remoting-bezogenen Objekte oder Methoden veraltet. Nach meinem Verständnis verwendet System.AddIn in den Frameworks 3.5 und 4.0 Remoting.

Hat jemand ein offizielles gegenteiliges Wort?

In dem Artikel Auswählen von Kommunikationsoptionen in .NET (für 3.0, da dies die neueste Version dieses Artikels ist) heißt es:

8 Anwendungsübergreifende Domänenkommunikation

Wenn Sie die Kommunikation zwischen Objekten in verschiedenen Anwendungsdomänen innerhalb desselben Prozesses unterstützen müssen, müssen Sie .NET-Remoting verwenden.

Nun, das ist natürlich nicht korrekt, da WCF sicherlich verwendet werden kann, um Appdomain-Grenzen zu überschreiten, aber gibt es die offizielle Empfehlung für dieses Szenario?

Update: Ich habe Clemens Vasters (der zu dem Team gehört, das Remoting und WCF besitzt) diese Frage geschickt:

Clemens, ich verstehe, dass Sie zu dem Team gehören, das sowohl Remoting als auch wcf besitzt, und ich habe ein paar Fragen, für die ich glaube, dass ich zur Quelle gehen muss.

Zunächst habe ich eine Frage, ob das Remoting nicht mehr funktioniert. Insbesondere haben wir eine ziemlich große Anwendung, die Remoting in großem Umfang für die prozessübergreifende Kommunikation zwischen Prozessen verwendet, und ich habe mich gefragt, ob diese Remoting-Verwendung als "Legacy" betrachtet wird. Wenn ja, werden AppDomain.CreateInstance und Freunde durch etwas anderes ersetzt?

Dies ist seine Antwort:

Remoting ist Teil des .Net Frameworks und wird daher nicht entfernt. COM ist seit Windows NT 3.5 / Windows 95 in Windows und ist nicht verschwunden, und ich sehe auch nicht, dass dies bald verschwindet.

Das heißt, es gibt nur sehr minimale Entwicklungsinvestitionen in Remoting. WCF ist der Nachfolger von Remoting und ersetzt COM / DCOM für verwalteten Code.

Für die prozessübergreifende, domänenübergreifende Kommunikation Remoting ist die native Kommunikationsmethode der CLR. Wenn Sie Leistungsprobleme feststellen, die in kurzer Zeit größere Datenmengen oder sehr viele Nachrichten pumpen, sollten Sie sich WCF und NetNamedPipeBinding genauer ansehen.


1
Unter stackoverflow.com/questions/1295353/… finden Sie eine Frage, warum WCF in meiner speziellen Situation so viel langsamer ist als Remoting.
Mark

1
Remoting ist ein wesentlicher Bestandteil von .NET, und Details zu seiner Rolle und Funktionsweise finden Sie in Essential .NET von Don Box und Chris Sells. Es fällt jedoch auseinander, wenn die Kommunikation zwischen Komponenten unzuverlässig oder langsam ist und praktisch alle Transporte - sogar ein Gigabit-LAN ​​- im Vergleich zu In-Process-Messaging unzuverlässig und langsam sind. Wenn Leute davon sprechen, dass WCF langsam ist, denken sie normalerweise an Webdienste. Webdienste sind zu langsam, wenn Sie versuchen, sie für In-Process-Kommunikation zu verwenden. Sie sind jedoch so konzipiert, dass sie langsame und unzuverlässige Verbindungen tolerieren und unter diesen Bedingungen gut funktionieren.
Peter Wone

3
@ Peter: Danke für die Informationen, aber einige Ihrer Annahmen sind völlig falsch. Erstens ist das Remoting langsam oder unzuverlässig. Es ist nicht. Es ist sehr schnell und sehr zuverlässig (natürlich über zuverlässige Kanäle). Ein weiterer Grund ist, dass "Webdienste" (was auch immer das bedeutet) langsam sind. Sie sind nicht. Natürlich wird alles, was in Bearbeitung ist, viel schneller sein als alles über das Netzwerk, aber darum geht es in dieser Frage überhaupt nicht ...
Mark

Antworten:


54

Die Bezeichnung "Legacy-Technologie" ist eine genauere Beschreibung.

http://msdn.microsoft.com/en-us/library/72x4h507%28VS.85%29.aspx

Dieses Thema bezieht sich speziell auf eine Legacy-Technologie, die aus Gründen der Abwärtskompatibilität mit vorhandenen Anwendungen beibehalten und für Neuentwicklungen nicht empfohlen wird. Verteilte Anwendungen sollten jetzt mit der Windows Communication Foundation (WCF) entwickelt werden.

Update: WCF unterscheidet nicht zwischen inter / intra / process / inter / intra-appdomain. Wenn Sie die Einzelmaschinenkommunikation in WCF verwenden, verwenden Sie Named Pipes. Die Verwendung dieser Kommunikation sollte in praktisch allen realistischen Szenarien eine gute Leistung bringen.

Einen Leistungsvergleich verschiedener verteilter Kommunikationstechnologien finden Sie hier .


Bezieht sich dieser Artikel nicht speziell auf die Verwendung von Remoting in der Interprozesskommunikation? Es scheint mir, dass Remoting immer noch einen Platz in der domänenübergreifenden Kommunikation hat (AppDomain.CreateInstanceFromAndUnwrap und Freunde).
Mark

Ja, so ist es. Wenn diese Klassen "veraltet" wären, würde das ObsoleteAttribute auf sie angewendet - msdn.microsoft.com/en-us/library/system.obsoleteattribute.aspx .
RichardOD

2
@Mark, @RichardOD: Der Artikel ist der Hauptartikel zu .NET Remoting. Es bezieht sich nicht nur auf die Kommunikation zwischen Prozessen. Auch die Tatsache, dass das ObsoleteAttribute in .NET 3.5 nicht auf ihnen enthalten ist, bedeutet nichts, da die Entscheidung, Remoting (und ASMX-Webdienste) als "Legacy" anzukündigen, nach .NET 3.5 RTM getroffen wurde.
John Saunders

@ John: Sie sind auch in 4.0 nicht als [veraltet] markiert (zumindest noch nicht).
Mark

@ Mark: Du meinst 4.0 Beta 1.
John Saunders

11

Ja. Remoting ist veraltet ... und offiziell von Microsoft. Hier ist der Link:

.NET Remoting

In der ersten Zeile des Artikels steht fett gedruckt:

Dieses Thema bezieht sich speziell auf eine Legacy-Technologie, die aus Gründen der Abwärtskompatibilität mit vorhandenen Anwendungen beibehalten und für Neuentwicklungen nicht empfohlen wird. Verteilte Anwendungen sollten jetzt mit der Windows Communication Foundation (WCF) entwickelt werden.

Ich dachte, die Redewendung sei "veraltet", aber anscheinend wird sie als "Vermächtnis" bezeichnet.


21
IMO 'veraltet' ist stärker als 'Legacy': 'Legacy' bedeutet "nicht starten" und veraltet bedeutet "Wenn Sie bereits gestartet haben, hören Sie jetzt auf, da es in zukünftigen Versionen möglicherweise vollständig entfernt wird".
ChrisW

1
@ Mark: Ich lese es nicht so. WCF scheint für die prozessinterne Kommunikation ebenso anwendbar zu sein wie Remoting (siehe NetNamedPipeBinding in WCF).
Michael Petrotta

1
@Mark: Unabhängig davon ist Remoting veraltet. @ChrisW: Ich bezweifle, dass Remoting in naher Zukunft entfernt wird, aber Sie können weniger Fehlerbehebungen (falls vorhanden) und weniger Unterstützung (falls vorhanden) erwarten.
John Saunders

1
@ Mark - was ist deine eigentliche Frage? Remoting wird als Legacy-Technologie betrachtet. Es hört sich so an, als ob Sie nicht möchten, dass das wahr ist. Sie haben vielleicht gute Gründe, aber das entspricht nicht wirklich den aktuellen Empfehlungen von Microsoft.
Michael Petrotta

1
@ John: Ich denke ich bin. Ich mache speziell prozessübergreifende domänenübergreifende Kommunikation (mit AppDomain.CreateInstanceFromAndUnwrap und Freunden), und ich sehe keinen Weg, dies mit WCF so sauber (oder so leistungsstark) zu machen. Ich verwende gerne stattdessen WCF (ich verwende es häufig in anderen Szenarien), aber dafür habe ich Probleme, es so zu machen, wie ich es möchte. Ich werde eine weitere Frage zu diesem speziellen Szenario stellen.
Mark

6

Wenn Sie auf .NET Core migrieren möchten, müssen Sie trotzdem eine andere Lösung für Remoting finden:

.NET Remoting wurde als problematische Architektur identifiziert. Es wird für die appDomainübergreifende Kommunikation verwendet, die nicht mehr unterstützt wird. Außerdem erfordert Remoting Laufzeitunterstützung, deren Wartung teuer ist. Aus diesen Gründen wird .NET Remoting in .NET Core nicht unterstützt, und wir planen nicht, in Zukunft Unterstützung dafür hinzuzufügen.

Quelle: https://docs.microsoft.com/en-us/dotnet/core/porting/libraries#remoting


1
Hier finden Sie eine Diskussion darüber, welche Alternativen in .NET Core verfügbar sind: github.com/dotnet/corefx/issues/18394
Jean-Claude


2

Clemens Vasters, der technische Leiter des Microsoft .NET Service Bus (dh sowohl Remoting als auch WCF), spricht in diesem Forumsbeitrag über WCF vs. Remoting . Um den Beitrag zusammenzufassen, empfiehlt er WCF gegenüber Remoting.

Ich bin nicht sicher, ob .NET 4.0 intern Remoting verwendet, aber Sie könnten versuchen, Clemens die Frage zu senden ... Ich bin sicher, er kennt die Antwort.


11
Ein Microsoft-Mitarbeiter, der die Verwendung der neuen Methode "Glänzend-Neu-Inkompatibel-mit-allem-Anderem" für jede Art von Standard empfiehlt? Schockierend.
Federbrecher

14
Inwiefern ist WCF nicht mit allem anderen kompatibel? Und Remoting war mit was kompatibel?
John Saunders

2
Wenn Sie nach Kompatibilität suchen, ist WCF die einzige Wahl (außer natürlich asmx, aber das ist auch "Vermächtnis"). Remoting war nie für Szenarien geeignet, in denen Kompatibilität erforderlich war.
Mark

3
Ich nahm Ihren Vorschlag an und fragte Clemens. Seine Antwort: "Remoting ist Teil des .Net Frameworks und wird daher nicht verschwinden ... Für die prozessübergreifende, domänenübergreifende Kommunikation Remoting ist die native Kommunikationsmethode der CLR."
Mark

1
Er fährt fort, dass Sie "WCF und NetNamedPipeBinding ernsthaft betrachten sollten".
John Saunders

2

Ich denke, dass es jetzt (2015) auch für anwendungsübergreifende Domänen ziemlich klar ist: https://msdn.microsoft.com/en-us/library/vstudio/ms180984(v=vs.100).aspx

Remoting Cross AppDomains Dieses Thema bezieht sich speziell auf eine Legacy-Technologie, die aus Gründen der Abwärtskompatibilität mit vorhandenen Anwendungen beibehalten und für Neuentwicklungen nicht empfohlen wird. Verteilte Anwendungen sollten jetzt mit der Windows Communication Foundation (WCF) entwickelt werden.

Dann sollte WCF auch für anwendungsübergreifende Domänen verwendet werden.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.