Nous utilisons TeamCity pour une intégration continue et nous construisons nos versions via le fichier de solution (.sln). J'ai utilisé Makefiles dans le passé pour divers systèmes mais jamais msbuild (ce que j'ai entendu est en quelque sorte comme Makefiles + mashup XML). J'ai vu de nombreux articles sur la façon d'utiliser directement msbuild au lieu des fichiers de solution, mais je ne vois pas de réponse très claire sur les raisons de le faire.
Alors, pourquoi devrions-nous prendre la peine de migrer des fichiers de solution vers un «makefile» MSBuild? Nous avons quelques versions qui diffèrent par une # définition (versions personnalisées), mais pour la plupart, tout fonctionne.
La plus grande préoccupation est que nous devions maintenant maintenir deux systèmes lors de l'ajout de projets / code source.
MISE À JOUR:
Les gens peuvent-ils faire la lumière sur le cycle de vie et l'interaction des trois composants suivants?
- Le fichier Visual Studio .sln
- Les nombreux fichiers .csproj au niveau du projet (que je comprends un "ms" scripts msbuild)
- Le script msbuild personnalisé
Est-il sûr de dire que les fichiers .sln et .csproj sont consommés / maintenus comme d'habitude à partir de l'interface graphique de Visual Studio IDE alors que le script msbuild personnalisé est écrit à la main et consomme généralement le .csproj individuel existant "tel quel"? C'est une façon dont je peux voir réduire les chevauchements / doublons dans la maintenance ...
J'apprécierais un peu la lumière de l'expérience opérationnelle d'autres personnes
Because it's reputed to be better practice
où?
So, why should we bother migrating from solution files to an MSBuild 'makefile'?
Vous devez d'abord vous dire pourquoi vous y pensez même? Le fichier de solution n'est-il pas suffisant?