C
Cedric
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 ?
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 ?