[Silverlight 3 + WCF] déploiement sur un serveur d'intégration

Le
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 ?
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Gilles TOURREAU
Le #20125071
Bonjour,

Une solution simple est de gérer plusieurs fichiers de configuration.
Par exemple :

- ServiceReferences.ClientConfig (Fichier pour les développeurs)
- ServiceReferences.ClientConfig.PreProducution (Fichier pour le test
d'intégration)

Dans CC.NET, dans le Build d'intégration, vous devez modifier votre fichier
de compilation afin d'utiliser le fichier
ServiceReferences.ClientConfig.PreProduction lors du déploiement de votre
application.

Beaucoup de personnes (y compris moi) utilisent cette méthode avec Team
Foundation Build.

Cordialement

--
Gilles TOURREAU - MVP C#
E-Mail :
Site Web : http://gilles.tourreau.fr

Société P.O.S - Le spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr

"Cedric" groupe de discussion :
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 ?


Publicité
Poster une réponse
Anonyme