Il s'agit d'essais de validation de Visual Studio .NET avec des sources C++ complexes utilisant notamment la STL et Loki.
Le client hésitait à faire passer de VS6 à VS.NET un ensemble d'applications dont certaines en cours de développement.
Il fallait aussi sélectionner une bibliothèque de Tests Unitaires.
Quelques extraits de mon rapport de novembre 2003 et de quelques mails.
Extrait d'un mail du 7/11/2003.
Pour pouvoir tester un peu, j'ai un WorkSpace qui comporte 2 projets : un EXE console et un DLL n'utilisant pas MFC. L'ensemble se crashe de manière prédictive sur accès à des objets collection STL créés par le DLL.
J'avais quelques idées pour tenter de courcircuiter le problème, mais j'ai préféré passer du temps sur le Web pour chercher de l'info valide. L'opinion générale est que l'ensemble Visual C++.NET/STL est plus stable.
Je peux continuer dans 2 directions :
Il ne faut pas oublier que des bibliothèques de sérialisation risquent également de faire appel à des Template que VC++ 6.0 aurait du mal à compiler correctement. Les bibliothèques de BOOST sont mieux gérées par VC++.NET.
Enfin dernière piste, surtout intéressante si vous conservez tout ou partie des développements sous VC6, utiliser STLPORT (voir extraits ci-dessous). C'est une bibliothèque que j'avais déja sélectionné en juin 2000 (puis utilisée pendant 18 mois). Elle fonctionnait mieux que celles livrées avec VC6 et GCC.
Quelques extraits de mon rapport du 21/11/2003.
A la suite de mes essais, je vous conseille d'utiliser Boost C++ Test Library pour réaliser des tests unitaires. Cette bibliothèque me paraît très robuste et bien documentée.
Je pense qu'elle doit manquer de possibilités d'extension du genre que pourrait permettre Cpp Utx. Mais ce n'est pas bien grave, car passer d'un cadre de tests à un autre n'est pas difficile. Pour l'instant il vous faut quelque chose de stable et simple d'emploi. Comme vous utiliserez probablement d'autres bibliothèques et outils de Boost, vous aurez une source commune, et cela simplifie toujours les choses.
J'ai aussi envisagé CppUnit que j'ai rejetée parce que l'architecture était moins intéressante que celle de CppUtx. Mais je n'ai pas trouvé d'implémentation stable de CppUtx.