[MsBuild] Un projet, plusieurs configurations, plusieurs jeux de références, c’est possible mais…
Je vais prendre pour exemple le développement avec les API de TFS. Si je veux pouvoir supporter VS 2010, VS 2008 avec ou sans compatibilité avec TFS 2010, je dois gérer 3 projets avec quasiment le même source. Une solution est de faire un projet puis d’ajouter des liens vers les fichiers pour chaque projet. Je vais vous proposer ici une autre solution basée sur MSBuild et la manipulation du fichier .csproj.
Si l’on regarde un fichier “.csproj” ou même “.vbproj” dans notepad, on se rend compte que le fichier est en fait un script MSBuild et que les références sont listées dans un “ItemGroup”:
Pour la démonstration je vais créer une Console avec 4 configurations. Ce qui va me permettre de développer l’application et aussi de pouvoir la compiler en Release pour chaque configuration:
- Release 2008
- Release 2010
- Debug 2008
- Debug 2010
On arrive alors dans cette état:
Ensuite, il suffit d’ouvrir le fichier de mon projet et d’ajouter 2 itemgroups: un pour chaque mode de compilation: 2008 ou 2010:
Comment cela se présente sous Visual Studio? Autant cela marche bien lors de l’édition de source (voir plus loin), autant dans le “Solution Explorer”, il y a eu mieux:
Coté source donc, le changement de configuration change le fonctionnement de VS. Voici du code pour 2008:
J’ai fait exprès de choisir ce bout de code car l’appel au constructeur du WorkItemStore est obsolète en 2010. Et c’est bien ce que me dis Visual Studio lorsque je change de mode:
En complétant ce mode de fonctionnement avec des “Define” spécifiques pour TFS 2008 et TFS 2010, on obtient un projet qui permet de compiler pour chaque plateforme.
Pour info, j’ai fait cette démo avec Visual Studio 2010, mais cela marche de la même façon avec Visual Studio 2008. Il faut prendre ce billet comme une démonstration de la souplesse de MSBuild que comme une démarche à suivre. Je préfère avoir plusieurs projets complètements isolés qu’à devoir gérer tout dans le même. Comme Visual Studio ne comprends pas forcément bien ce qu’il se passe, on ne peut pas prédire comment Visual Studio va se comporter avec les itemgroups et les conditions et il faut souvent revenir dans le source du fichier .csproj pour vérifier son contenu.
@+
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 :
