Bonjour,
Je développe un projet Silverlight + WCF en mode intégration continue, donc à chaque mise en conf de code l'application est déployée sur un serveur d'intégration (CCNet), buildée et les tests unitaires passés.
Je voudrais qu'à l'issue de cette étape on puisse faire des tests de validation plus poussés, donc hébergement des services WCF et de l'application Silverlight sur ce serveur d'intégration pour qu'on puisse y accéder et tester à distance.
Gros problème : par défaut dans Visual Studio les services WCF tournent sur le serveur de développement Cassini en local (donc http://localhost:1828 par exemple). Les références à ces services ajoutées dans le projet Silverlight pointent donc vers http://localhost:1828.
Il n'est pas envisageable que sur le serveur d'intégration les références continuent à pointer vers cette URL (un seul site Web sur le port 80, nécessité de ranger les services dans un répertoire précis, etc.). Malheureusement le fichier qui contient les références est zippé dans le .xap de l'application Silverlight, donc impossible de modifier les URL des services après build et déploiement sur le serveur d'intégration.
Il pourrait exister 2 autres solutions. En effet dans les propriétés du projet WCF on peut mettre les paramètres serveur à :
- Utiliser le serveur Web IIS local. Donc les services seront accessibles via http://localhost/myServices par exemple.
Le souci, c'est qu'automatiquement Visual Studio va transformer ça en http://ma_machine_de_dev.mondomaine.fr/myServices dans les références Silverlight (fichier ServiceReferences.ClientConfig). Evidemment tout tombe à l'eau puisque l'adresse ne sera plus valable sur le serveur d'intégration.- Utiliser le serveur web personnalisé. Ici on peut utiliser l'URL http://mon_serveur_integration/myServices. Le problème c'est qu'il faudra forcément avoir déployé la dernière version des services WCF sur le serveur d'intégration pour pouvoir tester l'application en local.
Adieu aussi le debug direct puisque les services WCF ne tournent plus sur Cassini. On en est réduit à analyser des messages d'erreur plus ou moins parlants renvoyés par le serveur d'intégration.
(je passe sur les soucis de CrossDomainPolicy liés à chacune de ces options, qui ont été résolus par des bidouilles plus infâmes les unes que les autres ^^)
Quelqu'un a-t-il déjà tenté la même expérience ? Comment garantir à la fois un bon niveau de débug des services WCF sur le poste du développeur et une automatisation du déploiement de ces services sur un serveur distant ?
Partager