J'ai lu beaucoup de questions (et de réponses) ici qui avaient des termes de sondage similaires dans cette question, mais toutes ont fini par être construites avec différentes versions majeures. de .Net. Je suis dans une situation beaucoup plus difficile, malheureusement.Choix du Service Pack du .Net Framework à compiler par rapport à
Voici l'histoire. Nos clients utilisent la version 2.0 du framework .Net. Juste 2.0, pas de service packs du tout. Nos développeurs utilisaient auparavant .Net 2.0 SP1, ce qui fonctionnait bien. Maintenant, en raison d'autres projets sur lesquels nous travaillons, les développeurs (moi inclus) ont mis à jour .Net 2.0 SP2. Et c'est là que les problèmes ont commencé. Apparemment, dans sa sagesse infinie, MS a décidé de modifier/ajouter API au cadre sans incrémenter la version majeure (à, disons, 2.1). Donc, quand vous construisez contre 2.0, il construit contre 2.0 SP2 (si vous l'avez installé) et il ne semble pas y avoir moyen de le configurer. Ainsi, le développeur peut désormais écrire du code en pensant cibler la version 2.0, mais cela ne fonctionnera pas sur les machines client!
Nous avons remarqué que certaines générations (effectuées à l'aide de msbuild) commençaient à échouer sur nos boîtes de test, mais fonctionnaient correctement sur les machines des développeurs. Évidemment, parce que la boîte de test est configurée de la même manière que les machines clientes, et que certaines de ces API manquent dans leur ancien framework. Maintenant, la batterie de build va installer la nouvelle version du CLR (incluant les packs spervice et les révisons majeurs plus élevés) pour tester tous nos projets, donc les builds qui utilisent l'API qui ne sont pas en 2.0 n'échoueront plus ... est une terrible nouvelle pour les tests de compatibilité.
Donc, ma question est la suivante. Comment construire (en utilisant msbuild) contre une révision CLR spécifique (de la même version majeure). A défaut, comment s'assurer que VS2005 génère une erreur lorsqu'un projet particulier utilise des fonctionnalités incompatibles avec une revsion particulière du CLR (pour jeter une clé dans les rouages, pas d'intégration FxCop ou similaire, fonctionnalités VS2005 de base uniquement)?
Si les questions ci-dessus n'ont pas de réponse positive, je suis tout à fait à la recherche de solutions de rechange.
Merci.
Le problème est que les développeurs (en particulier les nouveaux, ou certains qui portent le code d'autres projets) ont tendance à introduire des appels d'API incompatibles. En ce moment, il est complètement transparent pour le développeur et il n'y a aucun moyen de vous rattraper sans créer une liste noire et que les développeurs vérifient constamment à chaque fois qu'ils ajoutent quelque chose. –
Si vous trouvez que vous avez besoin de mettre à jour le SP de votre framework, alors il est logique que vos clients le suivent, sinon vous développez pour une plate-forme défectueuse. Cela dit, toutes les plateformes ne sont-elles pas défectueuses? ;) – Lazarus
Après tout, les mises à niveau sont gratuites (et oui, j'accepte que des coûts soient associés à la mise à niveau (si vous n'avez pas de solution de déploiement pour votre infrastructure.) De plus, si les stations de travail n'ont pas reçu mettre à jour alors quoi d'autre n'ont-ils pas reçu et combien de temps de soutien supplémentaire est gaspillé en supportant les environnements défectueux connus.Retour à mon premier commentaire à nouveau;) – Lazarus