Est-ce que .NET Remoting est vraiment obsolète?

95

Tout le monde dit comment .NET Remoting est remplacé par WCF, mais je me demande à quel point cela est précis. Je n'ai vu aucun mot officiel indiquant que Remoting est obsolète, et il me semble qu'il y a certainement des scénarios où Remoting a plus de sens que WCF. Aucun des objets ou méthodes liés à Remoting n'a été déconseillé, même dans la version 4.0 du framework. Je crois également comprendre que System.AddIn dans les frameworks 3.5 et 4.0 utilise Remoting.

Quelqu'un at-il un mot officiel du contraire?

Dans l'article, Choisir les options de communication dans .NET (pour 3.0, car il s'agit de la dernière version de cet article), il indique:

8 Communications entre domaines d'application

Si vous devez prendre en charge la communication entre des objets dans différents domaines d'application au sein du même processus, vous devez utiliser la communication à distance .NET.

Maintenant, bien sûr, ce n'est pas exact, car WCF peut certainement être utilisé pour traverser les limites du domaine d'application, mais donne-t-il la recommandation officielle pour ce scénario?

Mise à jour: j'ai envoyé cette question à Clemens Vasters (qui faisait partie de l'équipe qui possède Remoting et WCF):

Clemens, je crois comprendre que vous faites partie de l'équipe qui possède à la fois la télécommande et le wcf, et j'ai quelques questions pour lesquelles je pense que je dois aller à la source.

Premièrement, j'ai une question à savoir si la communication à distance va disparaître. Plus précisément, nous avons une application assez volumineuse qui utilise largement la communication à distance pour la communication inter-domaine d'application en cours de traitement, et je me demandais si cette utilisation de la communication à distance était considérée comme «héritée». Si tel est le cas, AppDomain.CreateInstance et ses amis seront-ils remplacés par autre chose?

Voici sa réponse:

La communication à distance fait partie du .Net Framework et en tant que telle, elle ne disparaîtra pas. COM est dans Windows depuis Windows NT 3.5 / Windows 95 et n'est pas parti et je ne vois pas cela disparaître de si tôt, non plus.

Cela dit, il y a un investissement de développement très minime dans Remoting. WCF est le successeur de Remoting et remplace COM / DCOM pour le code managé.

Pour les communications en cours et entre les domaines d'application, la communication à distance est le moyen de communication natif du CLR. Si vous rencontrez des problèmes de performances lors du pompage de plus grandes quantités de données ou de très nombreux messages en peu de temps, vous devez examiner sérieusement WCF et NetNamedPipeBinding.

.net wcf remoting

— marque
source

1

Voir stackoverflow.com/questions/1295353/ ... pour une question sur la raison pour laquelle WCF est tellement plus lent que Remoting dans ma situation spécifique.

— Mark

1

La communication à distance est intrinsèque à .NET, et les détails du rôle qu'il joue et de son fonctionnement peuvent être trouvés dans Essential .NET par Don Box et Chris Sells. Cependant, il s'effondre lorsque les communications inter-composants ne sont pas fiables ou lentes et que pratiquement tous les transports - même un LAN gigabit - ne sont pas fiables et lents par rapport à la messagerie en cours. Lorsque les gens disent que WCF est lent, ils pensent généralement aux services Web. Les services Web sont trop lents si vous essayez de les utiliser pour les communications en cours. Cependant, ils sont conçus pour tolérer des connexions lentes et peu fiables et fonctionnent bien dans ces conditions.

— Peter Wone

3

@ Peter: merci pour l'information, mais certaines de vos hypothèses sont complètement fausses. Premièrement, la communication à distance est lente ou peu fiable. Ce n'est pas. C'est très rapide et très fiable (sur des canaux fiables, bien sûr). Un autre est que les «services Web» (quoi que cela signifie) sont lents. Ils ne sont pas. Bien sûr, tout ce qui est en cours sera beaucoup plus rapide que tout sur le réseau, mais ce n'est pas du tout le sujet de cette question ...

— Mark

54

L'appeler une technologie héritée est une description plus précise.

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

Cette rubrique est spécifique à une technologie héritée qui est conservée à des fins de compatibilité descendante avec les applications existantes et n'est pas recommandée pour un nouveau développement. Les applications distribuées doivent maintenant être développées à l'aide de Windows Communication Foundation (WCF).

Mise à jour: WCF ne fait pas la distinction entre inter / intra / processus / inter / intra-domaine d'application. Si vous utilisez une communication avec une seule machine dans WCF, vous utilisez des canaux nommés - son utilisation devrait donner de bonnes performances dans pratiquement tous les scénarios réalistes.

Pour une comparaison des performances de diverses technologies de communication distribuées, voir ici .

— RichardOD
source

Cet article ne fait-il pas spécifiquement référence à l'utilisation de la communication à distance dans la communication interprocessus? Il me semble que la communication à distance a toujours sa place dans la communication inter-domaine d'application (AppDomain.CreateInstanceFromAndUnwrap et amis).

— Mark

Oui, ça l'est. Si ces classes avaient été «obsolètes», ils auraient le ObsoleteAttribute appliqué à eux - msdn.microsoft.com/en-us/library/system.obsoleteattribute.aspx .

— RichardOD

2

@Mark, @RichardOD: L'article est l'article principal sur .NET Remoting. Il ne se réfère pas seulement à la communication inter-processus. De plus, le fait que l'ObsoleteAttribute ne soit pas sur eux dans .NET 3.5 ne signifie rien, puisque la décision d'annoncer Remoting (et les services Web ASMX) comme «héritage» a été prise après .NET 3.5 RTM.

— John Saunders

@John: Ils ne sont pas non plus marqués [Obsolète] dans la version 4.0 (du moins pas encore).

— Mark

@Mark: vous voulez dire 4.0 beta 1.

— John Saunders

11

Oui. La communication à distance est obsolète ... et c'est officiel de Microsoft. Voici le lien:

Accès à distance .NET

La première ligne de l'article dit en gras:

Cette rubrique est spécifique à une technologie héritée qui est conservée à des fins de compatibilité descendante avec les applications existantes et n'est pas recommandée pour un nouveau développement. Les applications distribuées doivent maintenant être développées à l'aide de Windows Communication Foundation (WCF).

Je pensais que le verbiage était `` obsolète '' mais apparemment, ils l'appellent `` héritage ''

— Justin Niessner
source

21

L'OMI «obsolète» est plus fort que «hérité»: «hérité» signifie «ne pas démarrer», et «obsolète» signifie «si vous avez déjà commencé, arrêtez maintenant, car il pourrait être entièrement supprimé dans les versions futures».

— ChrisW

1

@Mark: Je ne le lis pas de cette façon. WCF semble aussi applicable pour la communication intra-processus que Remoting (voir NetNamedPipeBinding dans WCF).

— Michael Petrotta

1

@Mark: Quoi qu'il en soit, la communication à distance est obsolète. @ChrisW: Je doute que Remoting soit supprimé à court terme, mais vous pouvez vous attendre à moins de corrections de bogues, le cas échéant, et moins de support, le cas échéant.

— John Saunders

1

@Mark - quelle est votre vraie question? La communication à distance est considérée comme une technologie héritée. Il semble que vous ne souhaitiez pas que cela soit vrai. Vous pouvez avoir de bonnes raisons, mais cela ne correspond pas vraiment aux recommandations actuelles de Microsoft.

— Michael Petrotta

1

@John: Je suppose que je le suis. Je fais spécifiquement des communications inter-domaines d'application en cours (en utilisant AppDomain.CreateInstanceFromAndUnwrap et mes amis), et je ne vois pas de moyen de le faire aussi proprement (ou aussi performant) en utilisant WCF. Je suis heureux d'utiliser WCF à la place (je l'utilise beaucoup dans d'autres scénarios), mais pour cela, j'ai du mal à le faire fonctionner comme je le souhaite. Je posterai une autre question sur ce scénario spécifique.

— Mark

6

Si vous souhaitez migrer vers .NET Core, vous devez de toute façon trouver une autre solution pour Remoting:

.NET Remoting a été identifié comme une architecture problématique. Il est utilisé pour la communication inter-AppDomain, qui n'est plus prise en charge. En outre, la communication à distance nécessite une prise en charge de l'exécution, ce qui est coûteux à entretenir. Pour ces raisons, .NET Remoting n'est pas pris en charge sur .NET Core et nous ne prévoyons pas d'en ajouter une prise en charge à l'avenir.

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

— Jean-Claude
source

1

Ici vous pouvez trouver une discussion sur les alternatives disponibles dans .NET Core: github.com/dotnet/corefx/issues/18394

— Jean-Claude

Mentionné aussi ici: docs.microsoft.com/en-us/dotnet/core/porting

— Jean-Claude

2

Clemens Vasters, le responsable technique du bus de service Microsoft .NET (cela signifie à la fois Remoting et WCF) parle de WCF par rapport à Remoting dans ce message de forum . Pour résumer le message, il finit par recommander WCF sur Remoting.

Je ne sais pas si .NET 4.0 utilise la communication à distance en interne, mais vous pouvez essayer d'envoyer la question à Clemens ... Je suis sûr qu'il connaît la réponse.

— JohannesH
source

11

Un employé de Microsoft recommandant l'utilisation de la nouvelle méthode shiny-new-incompatible-with-else-else plutôt que n'importe quelle forme de standard? Choquant.

— quillbreaker

14

En quoi WCF n'est-il pas compatible avec tout le reste? Et Remoting était compatible avec quoi?

— John Saunders

2

Si vous recherchez la compatibilité, WCF est le -only- choix (sauf asmx, bien sûr, mais c'est aussi «hérité»). La communication à distance n'était jamais adaptée aux scénarios où la compatibilité était une exigence.

— Mark

3

J'ai pris votre suggestion et j'ai demandé à Clemens. Sa réponse: "La communication à distance fait partie du .Net Framework et, en tant que telle, elle ne disparaîtra pas ... Pour la communication en cours et entre les domaines d'application La communication à distance est le moyen de communication natif du CLR."

— Mark

1

Il poursuit en disant que vous devriez «jeter un regard sérieux sur WCF et NetNamedPipeBinding».

— John Saunders

2

Je pense que maintenant (2015) c'est assez clair même pour les domaines d'application croisés: https://msdn.microsoft.com/en-us/library/vstudio/ms180984(v=vs.100).aspx

Remoting Cross AppDomains Cette rubrique est spécifique à une technologie héritée qui est conservée pour la compatibilité descendante avec les applications existantes et n'est pas recommandée pour un nouveau développement. Les applications distribuées doivent maintenant être développées à l'aide de Windows Communication Foundation (WCF).

Ensuite, WCF doit également être utilisé pour les domaines d'application croisés.

— Armando
source