Les contrôles de santé en général sont un sujet assez difficile. Pour les fichiers construits dans Windows, il existe des outils comme SFC, mais cela ne s'étend pas aux autres paquets installés. Pour les packages MSI, vous pouvez choisir d'exécuter la réparation, et dans certains cas, Windows le fera automatiquement; ce sujet est généralement appelé Resiliency. Mais à moins que la réparation automatique ou manuelle répare les types de problèmes que vous rencontrez dans la nature, ce n'est pas très pertinent. La question se pose donc de savoir quels types de problèmes rencontrez-vous réellement, avec quelle fréquence, quelle est leur solution et quels sont les problèmes que vous pouvez rencontrer en essayant de les résoudre. S'il suffit d'invoquer une réparation manuelle du redist VC++, c'est assez facile à implémenter. Si une désinstallation complète et réinstallation est nécessaire, c'est beaucoup plus envahissant; l'idée de faire cette partie d'une installation me frotte dans le mauvais sens. Si vous devez le faire uniquement dans des situations très spécifiques, cela peut dépendre de votre capacité à identifier ces situations. Si vous vous concentrez sur la réussite de votre installation, vous pouvez peut-être lier statiquement vos DLL d'actions personnalisées afin qu'elles ne dépendent plus de l'état du package VC++. Cependant, cela n'aidera pas beaucoup votre application si l'application dépend également du paquetage VC++. Peut-être qu'une copie privatisée des DLLs VC++ peut-elle répondre à cela (si la version 2013 le supporte - j'oublie), au prix de plus de difficultés à gérer votre copie des DLL VC++ dans le cas de mises à jour de sécurité. Mais encore une fois, tout dépend des problèmes qui surviennent, qu'ils soient suffisamment fréquents pour qu'on puisse les résoudre et que la guérison soit pire que la maladie.