.NET Remoting è davvero deprecato?

95

Tutti dicono che .NET Remoting viene sostituito da WCF, ma mi chiedo quanto sia accurato. Non ho visto alcuna parola ufficiale secondo cui Remoting è stato deprecato e mi sembra che ci siano certamente scenari in cui il Remoting ha più senso di WCF. Nessuno degli oggetti o metodi relativi a Remoting è stato deprecato, anche nella versione 4.0 del framework. Sono anche consapevole del fatto che System.AddIn nei framework 3.5 e 4.0 utilizzi Remoting.

Qualcuno ha qualche parola ufficiale in contrario?

Nell'articolo, Scelta delle opzioni di comunicazione in .NET (per 3.0, poiché è l'ultima versione di quell'articolo), si afferma:

8 Comunicazioni tra domini applicativi

Se è necessario supportare la comunicazione tra oggetti in diversi domini dell'applicazione all'interno dello stesso processo, è necessario utilizzare .NET remoting.

Ora, questo, ovviamente, non è accurato, poiché WCF può certamente essere utilizzato per oltrepassare i confini del dominio app, ma fornisce la raccomandazione ufficiale per quello scenario?

Aggiornamento: ho inviato a Clemens Vasters (che faceva parte del team che possiede Remoting e WCF) questa domanda:

Clemens, mi risulta che tu faccia parte del team che possiede sia il controllo remoto che il wcf, e ho un paio di domande per le quali credo di dover andare alla fonte.

Innanzitutto, ho una domanda sul fatto che il telecomando stia andando via. Nello specifico, abbiamo un'applicazione piuttosto grande che utilizza ampiamente il telecomando per la comunicazione in-process tra domini di app e mi chiedevo se questo utilizzo del telecomando sia considerato "legacy". In tal caso, AppDomain.CreateInstance e gli amici verranno sostituiti con qualcos'altro?

Questa è la sua risposta:

Il servizio remoto fa parte di .Net Framework e come tale non scomparirà. COM è stato in Windows da Windows NT 3.5 / Windows 95 e non è andato via e non vedo che andrà via tanto presto.

Detto questo, l'investimento di sviluppo in Remoting è minimo. WCF è il successore di Remoting e sostituisce COM / DCOM per il codice gestito.

Per la comunicazione in-process, tra domini di app, il Remoting è il modo nativo di comunicazione di CLR. Se riscontri problemi di prestazioni durante il pompaggio di grandi quantità di dati o di molti messaggi in breve tempo, dovresti dare un'occhiata seria a WCF e NetNamedPipeBinding.

.net wcf remoting

— marchio
fonte

1

Vedi stackoverflow.com/questions/1295353/… per una domanda sul motivo per cui WCF è molto più lento del Remoting nella mia situazione specifica.

— Marco

1

Il remoting è intrinseco a .NET e i dettagli del ruolo che svolge e di come funziona possono essere trovati in Essential .NET di Don Box e Chris Sells. Tuttavia, cade a pezzi quando le comunicazioni tra componenti sono inaffidabili o lente e praticamente tutti i trasporti, anche una LAN gigabit, sono inaffidabili e lenti rispetto alla messaggistica in-process. Quando le persone parlano di WCF che è lento, di solito pensano ai servizi web. I servizi Web sono troppo lenti se si tenta di utilizzarli per le comunicazioni in-process. Tuttavia, sono progettati per tollerare connessioni lente e inaffidabili e funzionare bene in queste condizioni.

— Peter ha vinto il

3

@Peter: grazie per l'informazione, ma un paio di tue supposizioni sono completamente sbagliate. Uno, che la comunicazione remota è lenta o inaffidabile. Non è. È molto veloce e molto affidabile (su canali affidabili, ovviamente). Un altro è che i "servizi web" (qualunque cosa significhi) sono lenti. Loro non sono. Ovviamente, qualsiasi cosa in corso sarà molto più veloce di qualsiasi cosa sulla rete, ma non è affatto di questo che si tratta ...

— Mark

54

Definirla una tecnologia legacy è una descrizione più accurata.

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

Questo argomento è specifico per una tecnologia legacy che viene mantenuta per compatibilità con le versioni precedenti con le applicazioni esistenti e non è consigliato per il nuovo sviluppo. Le applicazioni distribuite dovrebbero ora essere sviluppate utilizzando Windows Communication Foundation (WCF).

Aggiornamento: WCF non distingue tra inter / intra / process / inter / intra-appdomain. Se si utilizza la comunicazione su una singola macchina in WCF, si utilizzano pipe denominate: il suo utilizzo dovrebbe fornire buone prestazioni praticamente in tutti gli scenari realistici.

Per un confronto delle prestazioni di varie tecnologie di comunicazione distribuita, vedere qui .

— RichardOD
fonte

Quell'articolo non si riferisce specificamente all'uso del telecomando nella comunicazione tra processi? Mi sembra che la comunicazione remota abbia ancora un posto nella comunicazione tra domini app (AppDomain.CreateInstanceFromAndUnwrap e amici).

— Mark

Sì. Se queste classi fossero state "deprecate", a esse sarebbe stato applicato ObsoleteAttribute- msdn.microsoft.com/en-us/library/system.obsoleteattribute.aspx .

— RichardOD

2

@Mark, @RichardOD: L'articolo è l'articolo principale su .NET Remoting. Non si riferisce solo alla comunicazione tra processi. Inoltre, il fatto che ObsoleteAttribute non sia presente in .NET 3.5 non significa nulla, poiché la decisione di annunciare Remoting (e servizi Web ASMX) come "legacy" è stata presa dopo .NET 3.5 RTM.

— John Saunders

@ John: Non sono contrassegnati come [Obsolete] neanche nella 4.0 (almeno non ancora).

— Marco

@Mark: intendi 4.0 beta 1.

— John Saunders

11

Sì. Il servizio remoto è deprecato ... ed è ufficiale di Microsoft. Ecco il link:

.NET Remoting

La prima riga dell'articolo dice in grassetto:

Questo argomento è specifico per una tecnologia legacy che viene mantenuta per compatibilità con le versioni precedenti con le applicazioni esistenti e non è consigliato per il nuovo sviluppo. Le applicazioni distribuite dovrebbero ora essere sviluppate utilizzando Windows Communication Foundation (WCF).

Pensavo che la verbosità fosse "deprecata" ma a quanto pare la chiamano "eredità"

— Justin Niessner
fonte

21

IMO "deprecated" è più forte di "legacy": "legacy" significa "non iniziare" e deprecated significa "se hai già iniziato, interrompi ora, perché potrebbe essere completamente rimosso nelle versioni future".

— ChrisW

1

@ Mark: non lo leggo in questo modo. WCF sembra applicabile per la comunicazione intra-processo come per i servizi remoti (vedere NetNamedPipeBinding in WCF).

— Michael Petrotta

1

@Mark: Indipendentemente da ciò, Remoting è deprecato. @ ChrisW: Dubito che il Remoting verrà rimosso a breve termine, ma puoi aspettarti meno correzioni di bug, se presenti, e meno supporto, se presente.

— John Saunders

1

@Mark - qual è la tua vera domanda? Il remoting è considerato una tecnologia legacy. Sembra che tu non desideri che sia vero. Potresti avere buone ragioni, ma questo non corrisponde alle attuali raccomandazioni di Microsoft.

— Michael Petrotta

1

@ John: credo di sì. Sto specificatamente facendo comunicazioni in-process cross-appdomain (usando AppDomain.CreateInstanceFromAndUnwrap e amici) e non vedo un modo per farlo in modo pulito (o ad alte prestazioni) usando WCF. Sono felice di usare WCF invece (lo uso molto in altri scenari), ma per questo ho problemi a farlo funzionare nel modo desiderato. Pubblicherò un'altra domanda su quello scenario specifico.

— Marco

6

Se desideri migrare a .NET Core devi comunque trovare un'altra soluzione per il Remoting:

.NET Remoting è stato identificato come un'architettura problematica. Viene utilizzato per la comunicazione tra AppDomain, che non è più supportata. Inoltre, i servizi remoti richiedono il supporto del runtime, che è costoso da mantenere. Per questi motivi, .NET Remoting non è supportato su .NET Core e non si prevede di aggiungerne il supporto in futuro.

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

— Jean-Claude
fonte

1

Qui puoi trovare una discussione su quali alternative sono disponibili in .NET Core: github.com/dotnet/corefx/issues/18394

— Jean-Claude

Menzionato anche qui: docs.microsoft.com/en-us/dotnet/core/porting/…

— Jean-Claude

2

Clemens Vasters, Technical Lead per il bus di servizio Microsoft .NET (che significa sia Remoting che WCF) parla di WCF e Remoting in questo post del forum . Per riassumere il post, finisce per consigliare WCF su Remoting.

Non sono sicuro che .NET 4.0 utilizzi il telecomando internamente, ma potresti provare a inviare la domanda a Clemens ... Sono sicuro che conosce la risposta.

— JohannesH
fonte

11

Un dipendente Microsoft che consiglia l'uso del nuovo metodo nuovo di zecca e incompatibile con tutto il resto su qualsiasi forma di standard? Scioccante.

— Quillbreaker

14

In che modo WCF non è compatibile con tutto il resto? E il Remoting era compatibile con cosa?

— John Saunders

2

Se stai cercando la compatibilità, WCF è l'unica scelta (tranne asmx, ovviamente, ma anche "legacy"). Il servizio remoto non era mai adatto per scenari in cui la compatibilità era un requisito.

— Marco

3

Ho accolto il tuo suggerimento e l'ho chiesto a Clemens. La sua risposta: "Il Remoting fa parte di .Net Framework e come tale non scomparirà ... Per la comunicazione in-process, tra domini di app, il Remoting è il modo nativo di comunicazione di CLR."

— Marco

1

Continua dicendo che dovresti "dare uno sguardo serio a WCF e NetNamedPipeBinding".

— John Saunders

2

Penso che ora (2015) sia abbastanza chiaro anche per i domini cross-application: https://msdn.microsoft.com/en-us/library/vstudio/ms180984(v=vs.100).aspx

Remoting Cross AppDomains Questo argomento è specifico per una tecnologia legacy che viene mantenuta per compatibilità con le applicazioni esistenti e non è consigliata per il nuovo sviluppo. Le applicazioni distribuite dovrebbero ora essere sviluppate utilizzando Windows Communication Foundation (WCF).

Quindi WCF dovrebbe essere utilizzato anche per domini di applicazioni incrociate.

— Armando
fonte