Linq to SQL + Web deployment : Fail ?
Sous ce titre un rien provocateur se cache un petit problème qui m’a valu une journée de perdue et quelques cheveux en moins.
Il s’agit d’une application web en apparence ordinaire, en .NET 3.5, avec dans la solution un projet de déploiement web (vdproj) servant à générer le package MSI utilisé pour l’installation du site.
Là où les choses commencent à devenir étranges, c’est que la compilation du projet de déploiement s’achève systématiquement sur le message « 7 succeded, 1 failed », alors qu’aucune erreur n’est affichée par le compilateur. Jusque là, personne ne s’en était vraiment soucié vu que le package MSI est quand même généré.
Les choses sont devenues plus gênantes quand je suis arrivé lundi avec pour tâche d’industrialiser les builds à l’aide de Team Foundation Server. Car bien évidemment, en détectant le message d’échec remonté par le compilateur, TFS arrête le processus de build et lève une erreur.
J’ai donc été forcé de me documenter sur le sujet, et, d’autres personnes s’étant trouvées dans la même situation, j’ai pu en trouver le coupable.
Il s'agit du module de validation des fichiers dbml générés par Linq to SQL. Le bug est d’ailleurs signalé sur Microsoft Connect : https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=317870. Notons ici le professionnalisme de Microsoft qui a fermé le rapport de bug sans donner de véritable solutions.
Les recherches sur divers blogs et forums m’ont permis de trouver deux solutions de contournement au problème :
La première, ajouter le paramètre /ResetSkipPkgs au lancement de Visual Studio. C’est le plus simple, mais ça n’a hélas pas marché dans mon cas.
Le second, modifier le fichier .csproj du projet contenant le diagramme dbml, et en retirer les lignes suivantes :
<ItemGroup>
<Service Include="{3259AA49-8AA1-44D3-9025-A0B520596A8C}" />
</ItemGroup>
Je me suis donc retrouvé avec trois possibilités :
- Appliquer la solution de contournement en modifiant le fichier .csproj
- Chercher un autre moyen de désactiver le composant incriminé
- Inclure au processus de build un script qui lance la génération des MSI, détecte s’ils ont bien été créés, et renvoie un code d’erreur approprié à TFS
La première possibilité était pour moi exclue d’office, car je ne voulais pas introduire de régressions. Les forums semblent dire qu’il n’y a aucun impact, mais je suis présent sur le projet depuis trop peu de temps pour pouvoir m’en assurer.
Je me suis donc attardé sur la seconde possibilité, et je me suis rendu compte que le problème pouvait être corrigé par la suppression d’une clé dans la base de registre. Cela empêche le chargement du composant incriminé et revient donc au final au même que la première solution, mais cette fois la modification se limite au serveur de builds, et n’impacte donc pas l’ensemble de l’équipe de développement.
La clé à supprimer est : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Services\{3259AA49-8AA1-44d3-9025-A0B520596A8C}
Je recommande bien entendu d’en faire une sauvegarde avant, pour pouvoir la restaurer rapidement en cas de problème.
A partir de là, il n’y a plus qu’à surveiller de près la qualité des builds en attendant un correctif officiel.
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
