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

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.

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 .

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 ''

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

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.

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.