La dernière mise à jour de sécurité de Visual Studio 2005 cause-t-elle des problèmes de bibliothèque C lors de la correction des sites clients?

Question

Comme vous le savez, une mise à jour de Visual Studio 2005 a été mise à jour automatiquement sur la plupart des machines la semaine dernière. Cette mise à jour comprenait une nouvelle version de la bibliothèque d'exécution Visual C. Par conséquent, tous les fichiers binaires créés après la mise à jour nécessitent également l'installation d'un nouveau fichier redistribuable sur les systèmes clients.

Voir http://support.microsoft.com/kb/971090/

Et voici le programme d'installation de la nouvelle redistribuable:

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=766a6af7-ec73-40ff-b072-9112bab119c2

C'est très bien pour la distribution de nouveaux fichiers binaires aux clients, j'embarquera le nouveau redistribuable avec l'installateur et Tout le monde travaillera.

Cependant, je suis vraiment inquiet au sujet de ma capacité à hotfixer des sites clients existants s'ils découvrent un bug. Dans ce cas normalement, je voudrais juste envoyer la DLL ou exe qui a été réparé.

Cependant, si je le fais maintenant, je vais devoir envoyer à ces clients le nouveau redistribuable et maintenant j'utiliserai deux versions différentes de la bibliothèque c runtime dans le même exécutable.

• Est-ce un problème?
• Mon application peut-elle se bloquer? Que se passe-t-il si j'alloue de la mémoire dans un DLL puis je l'abandonne dans un autre DLL? Normalement, cela fonctionne si la même bibliothèque d'exécution de version est utilisée. J'ai parcouru notre code il y a environ 3 ans, mais je ne peux pas être sûr d'avoir trouvé et corrigé toutes les occurrences.
• Est-ce que allocate/deallocate dans différentes DLL pose toujours un problème? Maintenant que dans l'ère des pointeurs intelligents, etc, il est très nécessaire d'appliquer cela. Puis-je contrôler la version de la bibliothèque d'exécution dont je dépend en changeant les manifestes?

Tout pointeur ou conseil serait reconnaissant.

Mise à jour: Je viens de remarquer cette question VC++: KB971090 and selecting Visual C Runtime DLL dependencies Ceci est très similaire, mais ma question est plus préoccupé par l'utilisation de deux versions différentes de l'exécution dans un exécutable.

Answer 1

Le numéro de version spécifié dans le fichier/ressource manifeste de l'application ne spécifie que la version minimale requise pour exécuter l'application. Le comportement par défaut du chargeur est d'abord vérifier le dossier WINDOWS \ WinSxS pour la version identique ou une version suppléante d'une dépendance identifiée dans un manifeste d'application, et d'utiliser cette version indépendamment du fait qu'un assembly privé contenant la dépendance a été ou non fourni avec l'application. (Voir http://msdn.microsoft.com/en-us/library/aa375674(VS.85).aspx).

Il est donc probable que vos anciens fichiers binaires utilisent également la dernière version de la bibliothèque Microsoft Runtime. Essayez d'exécuter la version finale de votre application (créée avant la mise à jour de Visual Studio) sur une machine entièrement patchée et utilisez l'explorateur de processus pour voir les DLL qu'elle charge. Le seul problème est que vous devrez inclure le nouveau fichier redistribuable dans votre patch.

Si vous êtes toujours inquiet, vous pouvez essayer la méthode décrite ici: http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/

Answer 2

Oui, vous ne devrez pas trop attendre pour voir les problèmes en utilisant deux bibliothèques d'exécution.

Si vous allouez de la mémoire à un environnement d'exécution et essayez de le libérer avec un autre, votre application se bloquera. C'est et continuera d'être un problème. Seul le temps d'exécution réservé à la mémoire peut le suivre. Il est impossible pour l'autre exécution de connaître la quantité de mémoire que vous avez réservée.

Vous voudrez peut-être lire this, est un très bon article sur la liaison avec msvcrt.dll.

Answer 3

J'ai entendu (seulement par la rumeur) que si le manifeste donne deux versions du CRT qui ne diffèrent que par un numéro de révision mineur, alors l'application finit seulement en utilisant la nouvelle version à l'exécution. Par exemple, vous ne rencontrez pas de problèmes avec plusieurs CRT.

Ceci est seulement une rumeur, et j'aimerais entendre une réponse concrète à ce sujet.

Voir aussi: Visual Studio 2005 security updates and CRT DLL versions in manifest