Confusion avec les espaces de noms Microsoft WebSockets

Question

Jusqu'à présent, dans les tutoriels, les blogs, et la documentation officielle, j'ai vu :

• Microsoft.Web.WebSockets
  • Obtenu à partir de NuGet
  • L'assemblage est Microsoft.WebSockets, mais l'espace de nom est Microsoft.Web.WebSockets.
  • Dernière mise à jour : 14 septembre 2011
  • Contient WebSocketHandler, WebSocketCollections, WebSocketExtensions
• System.Web.WebSockets
  • Fait partie de .NET 4.5 et est disponible dans Visual Studio 11 Developer Preview.
  • Contient les classes AspNetWebSocket, AspNetWebSocketContext et AspNetWebSocketOptions.
  • Documentation sur MSDN
• System.Net.WebSockets
  • Merci à Ladislav Mrnka de nous l'avoir signalé.
  • Fait partie de .NET 4.5 et est disponible dans Visual Studio 11 Developer Preview.
  • Contient WebSocket, HttpListenerWebSocketContext et plus encore.
  • Documentation sur MSDN
• System.ServiceModel.WebSockets
  • J'ai dû imaginer que j'avais vu celui-ci quelque part, je ne le trouve plus maintenant.
• Microsoft.ServiceModel.WebSockets
  • Obtenu auprès de html5labs.interoperabilitybridges.com/... .
  • Installé dans [Program Files]. \Microsoft SDKs \WCF WebSockets \11.06.22\bin
  • Contient les classes WebSocketHost, WebSocketService, WebSocketsService, ainsi que des interfaces et des collections.
  • Dernière mise à jour : 22 juin 2011

sont-elles en quelque sorte différentes ? Certaines sont-elles des versions plus anciennes ?

J'ai toujours supposé que l'espace de noms " Microsoft.Web " était utilisé pour le code de préversion, mais même les démos de la conférence Build utilisent cet espace de noms, malgré le fait que .NET 4.5 inclut l'espace de noms System.Web.WebSockets intégré.

System.Web.WebSockets semble avoir la même API que Microsoft.Web.WebSockets, mais avec des classes et des méthodes préfixées par AspNet.

System.ServiceModel.WebSockets fait partie de l'espace de noms WCF, qui semble également être un endroit judicieux pour mettre ce genre de choses.

À l'aide - Je suis confus. Que dois-je utiliser ?

Answer 1

Je vais ajouter un peu plus à votre confusion. Microsoft.* Les assemblages/espaces de noms préfixés sont généralement très spécifiques à un langage ou ne font pas partie du cadre .NET (livrés hors bande (ou prototypes)).

Les assemblages/espaces de noms livrés avec le cadre .NET commencent généralement par l'expression suivante System.* . Il existe deux espaces de noms contenant des fonctionnalités liées aux WebSockets dans .NET 4.5 :

• System.Net.WebSockets - mise en œuvre de WebSockets
• System.Web.WebSockets - intégration de WebSockets avec ASP.NET

Je n'ai pas vu System.ServiceModel.WebSockets mais je pense qu'il y avait un prototype nommé Microsoft.ServiceModel.WebSockets

Answer 2

html5labs.interoperabilitybridges.com :

...nous ne prévoyons pas de futures mises à jour de ce prototype.

System.Web.WebSockets :

...contient des classes qui permettent d'ajouter la fonctionnalité WebSocket à ASP.NET. Formulaires Web applications.

Microsoft.Web.WebSockets :

...fournit des fonctionnalités permettant d'écrire des applications serveur compatibles avec WebSocket sur Windows 8 en utilisant ASP.NET et WCF.

---

Ma conclusion :

• System.Net.WebSockets semble être quelque chose de bas niveau.
• System.Web.WebSockets dont vous avez besoin lorsque vous utilisez ASP.NET Formulaires Web
• Microsoft.Web.WebSockets de NuGet semble être le meilleur choix lorsque vous utilisez ASP.NET MVC

Answer 3

@Greg Woods concernant System.ServiceModel.WebSockets : vous ne l'avez pas imaginé.

http://html5labs.interoperabilitybridges.com/media/1165/readme.htm

Answer 4

Quant à la Microsoft.Web.WebSockets vs System.Web.WebSockets ...

Je le pense :

System.Web.WebSockets - vous donne un inférieur api pour travailler avec les websockets

alors que...

Microsoft.Web.WebSockets - est une sorte de plus haut api, ce qui le rend beaucoup plus facile à gérer, et tente également de refléter les événements/fonctions qui sont dans la spécification html5/javascript (par exemple, onerror, onopen, onmessage, onclose, send, etc...)

Answer 5

C'est ma conviction sur la raison pour laquelle la dénomination Microsoft.Web.WebSockets :

"Ce paquet d'aperçu fournit des fonctionnalités pour écrire des applications serveur compatibles avec WebSocket sur Windows 8 en utilisant ASP.NET et WCF. Nécessite .NET 4.5 RC et Windows 8 RC."

C'est probablement une bibliothèque nommée Microsoft.* car elle a été développée contre Windows 8 RC. Ce qui n'est pas une dépendance solide, donc elle ne peut pas faire partie du framework .net officiel.

Bien sûr, une fois que Windows 8 sera sorti, ils pourront compter sur lui et commencer à publier des bibliothèques websockets dans le cadre officiel. Ainsi, la bibliothèque Microsoft.Web.WebSockets peut être effectivement obsolète sans jamais quitter le statut de préversion.

Qu'en est-il System.Web.WebSockets vs System.Net.WebSockets ?

System.Web.WebSockets : "classes qui permettent d'ajouter la fonctionnalité WebSocket aux applications ASP.NET Web Forms".

Hm... Ça semble simple. Ces classes sont conçues pour être utilisées à partir de ASP.NET Web Forms. Ont-elles besoin de Windows 8 ? Pas sûr.

System.Net.WebSockets : est quelque chose d'autre qui n'est pas lié aux formulaires Web. Mais il ne fonctionne que si vous avez Windows 8.

Microsoft.ServiceModel.WebSockets

Un autre vieux paquet de préversion. Celui-ci fonctionne sous Windows 7 !

Note : au lieu de s'inquiéter de savoir ce qui fonctionne sur quelle plate-forme + cadre à utiliser pour obtenir WebSockets genre disparaît, vous pourriez simplement utiliser SignalR à la place, qui va choisir un transport et essayer de faire quelque chose comme websockets pour vous.