Blaise Braye, IT Edition

Je viens de passer deux jours sur un problème qui aurait pu être découvert instantanément si j'avais utilisé les bons outils tout de suite. (silverlight vs wcf ria services)

Généralement, les erreurs sont assez simple à obtenir via des points d'entrées standard tels qu'une récupération systématique des exceptions non gérées au niveau de l'application. Néanmoins, quand le problème vient d'une couche inférieure (data, transport), cela peut se corser sévèrement. il est possible de diagnostiquer rapidement les symptomes à l'aide de l'outil Fiddler. Une fois chargé, ce dernier écoute tous les allers-retours partant de votre client web. Mais certaines erreurs sont très sourdes : erreur 504, le serveur ne retourne pas de réponses...??? comment est-ce possible? a-t-on déjà vu une requête web sans réponse? à moins d'un problème sur la bande, ce devrait être impossible... Mais voilà, Microsoft a réussi à faire ça dans son conception des services wcf --> si une exception se produit à ce niveau, on en entend pas parler, on n'est même pas au courant qu'il y a un soucis à ce niveau. BRAVO.

Bref, une fois ce fait acquis, on cherche dans cette direction et on trouve rapidement ce type de post: wcf-ria-services-not-found-error-message.aspx et là, on se sent très bête... Cet outil devrait être l'un des premiers à prendre en main lorsque l'on développe avec des services WCF, c'est indispensable!

MS n'est certainement pas à blâmer dans cette histoire, alors Blaise, si tu développes des services WCF, il faut utiliser "Microsoft Trace Viewer" dès que Fiddler te parle d'une erreur 504!

Nous avons récemment eu des soucis pour manipuler les documents hébergés dans WSS à l'aide de WebDav. Ce problème est survenu suite à l'installation du "User Desktop Experience" sur le serveur windows server 2008 R2 qui héberge le portail (sous IIS7.5). Ce serveur est également le contrôleur de domaine principal du parc informatique.

le message d'erreur était assez difficile à interpréter, la commande net use nous retournait une erreur 67... vraissemblablement un "problème de mappage".

Après avoir cherché longuement une solution, on a bien fini par comprendre que WSS propose son propre redirecteur WebDav. Nous nous sommes donc occupés de désactiver WebDav sur tous les sites, le problème persistait... Nous avons alors cherché à voir si c'est un problème de droit, force est de constater que ça ne venait pas de là.
C'est finalement ce billet qui donne la bonne solution. Désactiver le redirecteur WebDav d'IIS ne suffit pas, il faut également supprimer le module "WebDAVModule" de la liste des modules IIS pour le site SharePoint concerné.