Pourquoi / comment migrer le service WCF auto-hébergé vers IIS7?

J’ai écrit quelques services WCF, que pour le développement et le débogage, j’ai couru comme auto-hébergé. Maintenant, j’ai un serveur Web et je réfléchis s’il y a une raison de changer mes services pour qu’ils fonctionnent sous IIS 7 … et si oui, comment? ..

MSDN a publié un article qui explore les différents modèles d’ hébergement WCF . Voici ce qu’il dit à propos de l’auto-hébergement:

Voici les avantages de l’auto-hébergement:

  • Facile à utiliser: votre service est en cours d’exécution avec seulement quelques lignes de code.
  • Est flexible: vous pouvez facilement contrôler la durée de vie de vos services via les méthodes Open () et Close () de ServiceHost.
  • Facile à déboguer: le débogage de services WCF hébergés dans un environnement auto-hébergé fournit un moyen de débogage familier, sans avoir à se connecter à des applications distinctes qui activent votre service.
  • Facile à déployer: En général, déployer des applications Windows simples est aussi simple que xcopy. Vous n’avez pas besoin de scénarios de déploiement complexes sur des batteries de serveurs, etc., pour déployer une application Windows simple faisant office de ServiceHost WCF.
  • Prend en charge toutes les liaisons et tous les transports: l’auto-hébergement ne vous limite pas aux liaisons et aux transports prêts à l’emploi. Sous Windows XP et Windows Server 2003, IIS vous limite à HTTP.

Les inconvénients de l’auto-hébergement sont les suivants:

  • Disponibilité limitée: le service est accessible uniquement lorsque l’application est en cours d’exécution.
  • Fonctionnalités limitées: les applications auto-hébergées prennent en charge de manière limitée la haute disponibilité, la facilité de gestion, la robustesse, la récupérabilité, la gestion des versions et les scénarios de déploiement. Au moins, WCF prête à l’emploi ne fournit pas ces informations. Par conséquent, dans un scénario auto-hébergé, vous devez implémenter ces fonctionnalités vous-même. IIS, par exemple, est livré avec plusieurs de ces fonctionnalités par défaut.

Si ce n’est pas cassé 🙂

Sérieusement: ne faites pas net.tcp WCF dans IIS. Vous sauve beaucoup de maux de tête. HTTP WCF devrait bien se passer.

J’envisagerais de créer un nouveau projet en utilisant le modèle de projet “Application de service WCF” de VS2010. Vous pouvez même simplement faire référence à votre assemblée originale, je suppose. Le point est, si vous utilisez ce modèle, VS2010 affiche une nouvelle barre d’outils qui vous permet de publier sur un serveur IIS qui effectue tout le “travail difficile” de la création des bons fichiers et dossiers de configuration.

Bonne suggestion. Voici les étapes exactes que j’ai utilisées pour convertir l’auto-hébergé en IIS hébergé:

Étape 1: Créer une application de service .NET Framework 4 WCF
Étape 2: Ajoutez une référence aux DLL WCF.
Étape 3: Faites un clic droit sur Service1.scv (généré automatiquement) et sélectionnez “Afficher le balisage”. Il devrait ressembler à ceci: code <% @ ServiceHost Language = "C #" Debug = "true" Service = "WcfService4.Service1" CodeBehind = " Service1.svc.cs "%> code.
Étape 4: remplacez “… Service1” par les services des DLL. Supprimez la balise CodeBehind = “Service1.svc.cs”.
Étape 5: Faites un clic droit sur la solution, Publiez sur votre serveur / page. Activez “Marquer comme IIS …”.
Étape 6: ouvrez votre serveur / votre page / Service1.scv