Partager via

Vue d’ensemble des problèmes de mise à niveau potentiels (Visual C++)

  • Article

Au fil des années, le compilateur Microsoft C++ a subi de nombreuses modifications, avec des changements apportés au langage C++ lui-même, à la bibliothèque C++ standard, à la bibliothèque Runtime C (CRT) et à d’autres bibliothèques telles que MFC et ATL. Par conséquent, lorsque vous mettez à niveau une application à partir d’une version antérieure de Visual Studio, vous pouvez voir les erreurs et avertissements du compilateur et de l’éditeur de liens dans le code qui ont été compilés correctement. Plus la base de code d’origine est ancienne, plus le risque de telles erreurs est élevé. Cette vue d’ensemble récapitule les classes de problèmes les plus courantes que vous pouvez voir et fournit des liens vers des informations plus détaillées.

Remarque

Dans le passé, nous avons recommandé que les mises à niveau qui s’étendent sur plusieurs versions de Visual Studio soient effectuées de manière incrémentielle une version à la fois. Nous ne conseillons plus cette démarche. Nous avons constaté qu’il est presque toujours plus simple de procéder à la mise à niveau vers la version la plus récente de Visual Studio, quelle que soit l’ancienne base du code.

Les questions ou commentaires concernant le processus de mise à niveau peuvent être envoyés à vcupgrade@microsoft.com.

Dépendances de bibliothèque et d’ensemble d’outils

Remarque

Cette section s’applique aux applications et bibliothèques générées avec Visual Studio 2013 et antérieur. Les ensembles d’outils utilisés dans Visual Studio 2015, Visual Studio 2017 et Visual Studio 2019 sont binairement compatibles. Pour plus d’informations, consultez Compatibilité binaire C++ entre les versions de Visual Studio.

Lorsque vous mettez à niveau une application de Visual Studio 2013 ou avant vers une version plus récente, il est souvent recommandé et nécessaire de mettre à niveau toutes les bibliothèques et DLL vers lesquelles l’application est liée. Soit vous devez avoir accès au code source, soit le fournisseur de bibliothèque doit fournir de nouveaux fichiers binaires compilés avec la même version principale du compilateur. Si l’une de ces conditions est remplie, vous pouvez ignorer cette section, qui aborde les détails de la compatibilité binaire. Si aucun des deux n’est le cas, les bibliothèques peuvent ne pas fonctionner dans votre application mise à niveau. Les informations de cette section vous aideront à comprendre si vous pouvez poursuivre la mise à niveau.

Ensemble d'outils

Les .obj formats et .lib les formats de fichier sont bien définis et changent rarement. Des éléments sont parfois ajoutés à ces formats de fichiers, mais ces ajouts n’affectent généralement pas la capacité des ensembles d’outils plus récents à consommer les fichiers objets et les bibliothèques produits par des ensembles d’outils plus anciens. L’exception principale est si vous compilez à l’aide /GL de l’ensemble du programme. Si vous compilez à l’aide /GL, vous pouvez lier uniquement le fichier objet résultant à l’aide du même ensemble d’outils utilisé pour le produire. Par conséquent, si vous produisez un fichier objet avec /GL un compilateur Visual Studio 2017 (v141), vous devez le lier à l’aide de l’éditeur de liens Visual Studio 2017 (v141). Cela est dû au fait que les structures de données internes au sein des fichiers objet ne sont pas stables dans les versions majeures de l’ensemble d’outils. Les ensembles d’outils plus récents ne comprennent pas les formats de données plus anciens.

C++ ne dispose pas d’une interface ABI (Application Binary Interface) stable. En revanche, Visual Studio gère une interface ABI C++ stable pour toutes les versions secondaires d’une version. Les ensembles d’outils Visual Studio 2015 (v140), Visual Studio 2017 (v141), Visual Studio 2019 (v142) et Visual Studio 2022 (v143) varient uniquement dans leur version mineure. Elles ont toutes le même numéro de version principale, qui est 14. Pour plus d’informations, consultez Compatibilité binaire C++ entre les versions de Visual Studio.

Si vous avez un fichier objet qui contient des symboles externes avec une liaison C++, ce fichier objet peut ne pas être lié correctement aux fichiers objets générés par une version principale différente de l’ensemble d’outils. Il existe de nombreux résultats possibles : le lien peut échouer entièrement (par exemple, si la décoration du nom a changé). Le lien peut réussir, mais l’application peut échouer au moment de l’exécution (par exemple, si les dispositions de type ont changé). Ou votre application peut continuer à fonctionner et rien ne va mal. Notez également que si l’ABI C++ n’est pas stable, l’ABI C et le sous-ensemble de l’ABI C++ requis pour COM sont stables.

Si vous créez un lien à une bibliothèque d’importation, les versions ultérieures des bibliothèques redistribuables Visual Studio qui conservent une compatibilité avec l’ABI peuvent être utilisées lors de l’exécution. Par exemple, si vous compilez et liez votre application à l’aide de l’ensemble d’outils Visual Studio 2015 Update 3, vous pouvez utiliser n’importe quel redistribuable ultérieurement. C’est parce que les bibliothèques 2015, 2017, 2019 et 2022 ont conservé la compatibilité binaire descendante. L’inverse n’est pas vrai : vous ne pouvez pas utiliser de redistribuable pour une version antérieure de l’ensemble d’outils que vous avez utilisé pour générer n’importe quel composant de votre code.

Bibliothèques

Si vous #include avez une version particulière des fichiers d’en-tête, vous devez lier le fichier objet résultant à la même version des bibliothèques. Par exemple, si votre fichier source inclut Visual Studio 2015 Update 3 <immintrin.h>, vous devez établir un lien avec la bibliothèque Visual Studio 2015 Update 3 vcruntime . De même, si votre fichier source inclut la version 15.5 <iostream>de Visual Studio 2017, vous devez établir un lien avec la bibliothèque C++ de Visual Studio 2017 version 15.5 Standard, msvcprt. Le mélange et la correspondance ne sont pas pris en charge.

Pour la bibliothèque standard C++, le mélange et la correspondance ont été explicitement interdits par l’utilisation des #pragma detect_mismatch en-têtes standard depuis Visual Studio 2010. Si vous essayez de lier des fichiers objet incompatibles ou si vous liez avec la bibliothèque standard incorrecte, le lien échoue.

L’ancienne version CRT mix-and-matching n’a jamais été prise en charge, mais elle a souvent fonctionné parce que la surface de l’API ne change pas beaucoup au fil du temps. La bibliothèque Universal CRT a révélé la compatibilité descendante pour que nous puissions la gérer à l’avenir. Nous n’avons pas l’intention d’introduire de nouveaux fichiers binaires CRT versionnés à l’avenir. Au lieu de cela, la bibliothèque Universal CRT existante est désormais mise à jour sur place.

Pour assurer une compatibilité partielle des liens avec les fichiers objet (et bibliothèques) compilés avec les versions antérieures des en-têtes Microsoft C Runtime, nous fournissons une bibliothèque, legacy_stdio_definitions.libavec Visual Studio 2015 et versions ultérieures. Cette bibliothèque fournit des symboles de compatibilité pour la plupart des fonctions et exportations de données qui ont été supprimées de la bibliothèque Universal CRT. L’ensemble de symboles de compatibilité fournis par legacy_stdio_definitions.lib est suffisant pour satisfaire la plupart des dépendances, y compris toutes les dépendances dans les bibliothèques incluses dans le Kit de développement logiciel (SDK) Windows. Toutefois, certains symboles ont été supprimés du CRT universel qui n’ont pas de symboles de compatibilité. Ces symboles incluent à la fois certaines fonctions (par exemple, __iob_func) et certaines exportations de données (par exemple, , __imp___iob, __imp___pctype__imp___mb_cur_max).

Si vous disposez d’une bibliothèque statique générée à l’aide d’une version antérieure des en-têtes C Runtime, nous vous recommandons les actions suivantes, dans cet ordre :

  1. Regénérez la bibliothèque statique à l’aide de la nouvelle version de Visual Studio et des en-têtes Universal CRT pour prendre en charge la liaison avec la bibliothèque Universal CRT. Cette approche est entièrement prise en charge et la meilleure option.

  2. Si vous ne pouvez pas (ou ne souhaitez pas) reconstruire la bibliothèque statique, vous pouvez essayer de lier avec legacy_stdio_definitions.lib. S’il satisfait aux dépendances au moment du lien de votre bibliothèque statique, vous devez tester soigneusement la bibliothèque statique telle qu’elle est utilisée dans le fichier binaire. Assurez-vous qu’elle n’est pas affectée par les modifications comportementales apportées au CRT universel.

  3. Les dépendances de votre bibliothèque statique ne sont peut-être pas satisfaites legacy_stdio_definitions.lib ou la bibliothèque ne fonctionne pas avec le CRT universel en raison des modifications de comportement. Dans ce cas, nous vous recommandons d’encapsuler votre bibliothèque statique dans une DLL que vous liez avec la version requise du Microsoft C Runtime. Par exemple, si la bibliothèque statique a été créée à l’aide de Visual Studio 2013, générez cette DLL à l’aide de l’ensemble d’outils Visual Studio 2013 et des bibliothèques C++. Par la génération de la bibliothèque dans une DLL, vous encapsulez le détail d’implémentation qui est sa dépendance sur une version particulière du Runtime C de Microsoft. Veillez à ce que l’interface DLL ne fuite pas les détails du runtime C qu’il utilise, par exemple, s’il retourne une FILE* limite de DLL, ou un mallocpointeur alloué que l’appelant doit free.

L’utilisation de plusieurs CRT dans un seul processus n’est pas en soi problématique. (En fait, la plupart des processus chargent plusieurs DLL CRT. Par exemple, les composants du système d’exploitation Windows dépendent msvcrt.dll, et le CLR dépend de son propre CRT privé.) Des problèmes se produisent lorsque vous mettez à jour l’état de différents CRT. Par exemple, vous ne devez pas allouer de mémoire à l’aide msvcr110.dll!malloc de cette mémoire et tenter de libérer cette mémoire à l’aide msvcr120.dll!freede , et vous ne devez pas essayer d’ouvrir un FICHIER à l’aide msvcr110!fopen et tenter de lire à partir de ce FICHIER à l’aide msvcr120!fread. Tant que vous n’avez pas d’état d’arrêt à partir de différents CRT, vous pouvez avoir en toute sécurité plusieurs CRT chargés dans un seul processus.

Pour plus d’informations, consultez Mettre à niveau votre code vers la bibliothèque Universal CRT.

Erreurs provoquées par les paramètres du projet

Pour commencer le processus de mise à niveau, ouvrez un projet/solution/espace de travail plus ancien dans la dernière version de Visual Studio. Visual Studio crée un projet basé sur les anciens paramètres de projet. Vérifiez si l’ancien projet possède des chemins de bibliothèque ou inclut des chemins codés en dur vers des emplacements non standard. Il est possible que les fichiers de ces chemins d’accès ne soient pas visibles par le compilateur lorsque le projet utilise les paramètres par défaut. Pour plus d’informations, consultez Paramètre OutputFile de l’éditeur de liens.

En général, il est très utile d’organiser votre code de projet pour simplifier la maintenance du projet et aider à obtenir votre code mis à niveau pour générer le plus rapidement possible. Si votre code source est déjà bien organisé et que votre projet plus ancien est compilé sous Visual Studio 2010 ou version ultérieure, vous pouvez modifier manuellement le nouveau fichier projet pour prendre en charge la compilation sur l’ancien et le nouveau compilateur. L’exemple suivant montre comment effectuer la compilation pour Visual Studio 2015 et Visual Studio 2017 :

<PlatformToolset Condition="'$(VisualStudioVersion)'=='14.0'">v140</PlatformToolset>
<PlatformToolset Condition="'$(VisualStudioVersion)'=='15.0'">v141</PlatformToolset>

LNK2019 : Symbole externe non résolu

Pour les symboles non résolus, vous devez peut-être corriger les paramètres de votre projet.

  • Si le fichier source se trouve à un emplacement non par défaut, avez-vous ajouté le chemin d’accès aux répertoires include du projet ?

  • Si l’externe est défini dans un .lib fichier, avez-vous spécifié le chemin d’accès de bibliothèque dans les propriétés du projet et est-il la version correcte du .lib fichier situé ici ?

  • Essayez-vous de créer un lien vers un .lib fichier compilé avec une autre version de Visual Studio ? Dans ce cas, consultez la section précédente sur les dépendances de bibliothèque et d’ensemble d’outils.

  • Est-ce que les types des arguments du site d’appel correspondent réellement à une surcharge existante de la fonction ? Vérifiez que les types sous-jacents sont ce que vous attendez, tant pour tous les typesdefs dans la signature de la fonction que dans le code qui appelle la fonction.

Pour résoudre les erreurs de symbole non résolues, vous pouvez utiliser dumpbin.exe pour examiner les symboles définis dans un fichier binaire. Essayez d’utiliser la ligne de commande ci-dessous pour afficher les symboles définis dans une bibliothèque :

dumpbin.exe /LINKERMEMBER somelibrary.lib

/Zc:wchar_t (wchar_t Type natif)

(Dans Microsoft Visual C++ 6.0 et versions antérieures, wchar_t n’a pas été implémenté en tant que type intégré. Il a été déclaré en wchar.h tant que typedef pour unsigned short.) La norme C++ nécessite qu’il s’agit wchar_t d’un type intégré. L’utilisation de la version typedef peut entraîner des problèmes de portabilité. Si vous effectuez une mise à niveau à partir de versions antérieures de Visual Studio et que vous voyez l’erreur du compilateur C2664, car le code tente implicitement de convertir un wchar_t unsigned shortcode en , nous vous recommandons de modifier le code pour corriger l’erreur, au lieu de définir /Zc:wchar_t-. Pour plus d’informations, consultez /Zc:wchar_t (wchar_t type natif).

Mise à niveau avec les options /NODEFAULTLIBde l’éditeur de liens , /ENTRYet /NOENTRY

L’option /NODEFAULTLIB éditeur de liens (ou la propriété Ignorer toutes les bibliothèques par défaut) indique à l’éditeur de liens de ne pas lier automatiquement dans les bibliothèques par défaut telles que le CRT. Cela signifie que chaque bibliothèque doit être listée individuellement comme entrée. Cette liste de bibliothèques est indiquée dans la propriété Dépendances supplémentaires de la section Éditeur de liens de la boîte de dialogue Propriétés du projet.

Les projets qui utilisent cette option posent un problème lors de la mise à niveau, car les contenu de certaines des bibliothèques par défaut a été refactorisée. Comme chaque bibliothèque doit être listée dans la propriété Dépendances supplémentaires ou sur la ligne de commande de l’éditeur de liens, vous devez mettre à jour la liste des bibliothèques pour utiliser tous les noms actuels.

Le tableau suivant présente les bibliothèques dont le contenu a changé à compter de Visual Studio 2015. Pour effectuer une mise à niveau, vous devez ajouter les nouveaux noms de bibliothèques de la deuxième colonne dans les bibliothèques de la première colonne. Certaines de ces bibliothèques sont des bibliothèques d’importation, mais cela ne doit pas être important.

Si vous utilisiez : Vous devez utiliser ces bibliothèques :
libcmt.lib libcmt.lib, , libucrt.liblibvcruntime.lib
libcmtd.lib libcmtd.lib, , libucrtd.liblibvcruntimed.lib
msvcrt.lib msvcrt.lib, , ucrt.libvcruntime.lib
msvcrtd.lib msvcrtd.lib, , ucrtd.libvcruntimed.lib

Le même problème se pose si vous utilisez les options /ENTRY ou /NOENTRY, qui ont également pour effet de contourner les bibliothèques par défaut.

Erreurs provoquées par une conformité de langage améliorée

Le compilateur Microsoft C++ a constamment amélioré sa conformité à la norme C++ au fil des années. Le code compilé dans les versions antérieures peut échouer à compiler dans les versions ultérieures de Visual Studio. Cela est dû au fait que le compilateur signale correctement une erreur qu’il a précédemment ignorée ou explicitement autorisée.

Par exemple, le commutateur /Zc:forScope a été introduit aux origines de MSVC. Il autorise un comportement non conforme pour les variables de boucle. Ce commutateur est maintenant déprécié et peut être supprimé dans les prochaines versions. Nous vous recommandons vivement de ne pas utiliser ce commutateur lors de la mise à niveau de votre code. Pour plus d’informations, consultez /Zc:forScope- la section déconseillée.

Un argument non const passé à un paramètre const est un exemple d’erreur de compilateur courante que vous pouvez rencontrer lors de la mise à niveau. Les versions antérieures du compilateur ne l’ont pas toujours indiqué comme une erreur. Pour plus d’informations, consultez Conversions plus strictes du compilateur.

Pour plus d’informations sur les améliorations apportées à la conformité, consultez Historique des modifications de Visual C++ entre 2003 et 2015 et Améliorations de la conformité de C++ dans Visual Studio.

Erreurs impliquant des <stdint.h> types intégraux

L’en-tête <stdint.h> définit les typesdefs et les macros qui, contrairement aux types intégraux intégrés intégrés, sont garanties d’avoir une longueur spécifiée sur toutes les plateformes. Voici des exemples : uint32_t et int64_t. L’en-tête <stdint.h> a été ajouté dans Visual Studio 2010. Le code écrit avant 2010 peut avoir fourni des définitions privées pour ces types. Et ces définitions peuvent ne pas toujours être cohérentes avec les <stdint.h> définitions.

Si l’erreur est C2371 et qu’un stdint type est impliqué, cela signifie probablement que le type est défini dans un en-tête dans votre code ou dans un fichier de bibliothèque tiers. Lors de la mise à niveau, vous devez éliminer les définitions personnalisées des <stdint.h> types, mais tout d’abord comparer les définitions personnalisées aux définitions standard actuelles pour vous assurer que vous n’introduisez pas de nouveaux problèmes.

Vous pouvez appuyer sur F12 (Atteindre la définition) pour voir où le type en question est défini.

L’option /showIncludes du compilateur peut être utile ici. Dans la boîte de dialogue Pages de propriétés de votre projet, sélectionnez la page Propriétés>de configuration C/C++>Avancé et définissez Afficher les éléments inclus sur Oui. Régénérez ensuite votre projet. Vous verrez la liste des #include fichiers dans la fenêtre de sortie. Chaque en-tête est mis en retrait sous l’en-tête qui l’inclut.

Erreurs impliquant des fonctions CRT

De nombreuses modifications ont été apportées au Runtime C au fil des années. De nombreuses versions sécurisées de fonctions ont été ajoutées et certaines ont été supprimées. En outre, comme décrit précédemment dans cet article, l’implémentation de Microsoft du CRT a été refactorisé dans Visual Studio 2015 en nouveaux fichiers binaires et fichiers associés .lib .

Si une erreur implique une fonction CRT, effectuez des recherches dans Historique des modifications de Visual C++ entre 2003 et 2015 ou Améliorations de la conformité de C++ dans Visual Studio pour voir si ces articles contiennent des informations supplémentaires. Si l’erreur est LNK2019, vérifiez que la fonction n’a pas été supprimée. Sinon, si vous êtes sûr que la fonction existe toujours et que le code appelant est correct, vérifiez si votre projet utilise /NODEFAULTLIB. Dans ce cas, vous devez mettre à jour la liste des bibliothèques pour utiliser les nouvelles bibliothèques universelles (UCRT). Pour plus d’informations, consultez la section ci-dessus sur les dépendances de bibliothèque.

Si l’erreur implique printf ou scanf, assurez-vous que vous ne définissez pas en privé une fonction sans inclure stdio.h. Si c’est le cas, supprimez les définitions privées ou liez à legacy_stdio_definitions.lib. Vous pouvez définir cette bibliothèque dans la boîte de dialogue Pages de propriétés sous Propriétés de configuration>Éditeur de liens>Entrée, dans la propriété Dépendances supplémentaires. Si vous liez avec le Kit de développement logiciel (SDK) Windows 8.1 ou version antérieure, ajoutez legacy_stdio_definitions.lib.

Si l’erreur implique des arguments de chaîne de format, le compilateur est probablement plus strict sur l’application de la norme. Pour plus d’informations, consultez l’historique des modifications. Prêtez une attention toute particulière aux erreurs ici, car elles peuvent potentiellement représenter un risque pour la sécurité.

Erreurs provoquées par les modifications apportées à la norme C++

La norme C++ elle-même a évolué de manière à ne pas toujours être compatible descendante. C++11 a introduit la sémantique de déplacement, les nouveaux mots clés et d’autres fonctionnalités de la bibliothèque standard et du langage. Ces modifications peuvent potentiellement entraîner des erreurs de compilateur et même un comportement d’exécution différent.

Par exemple, un ancien programme C++ peut inclure l’en-tête iostream.h . Cet en-tête a été déprécié au début de l’historique de C++ et a finalement été entièrement supprimé de Visual Studio. Dans ce cas, vous devez utiliser <iostream> et réécrire votre code. Pour plus d’informations, consultez Mise à jour de l’ancien iostream code.

C4838 : Avertissement de conversion restrictive

La norme C++ spécifie désormais que les conversions de valeurs intégrales non signées en valeurs intégrales signées réduisent les conversions. Le compilateur n’a pas soulevé cet avertissement avant Visual Studio 2015. Inspectez chaque occurrence pour vous assurer que le rétrécissement n’affecte pas la justesse de votre code.

Avertissements pour utiliser des fonctions CRT sécurisées

Au fil des années, des versions sécurisées de fonctions Runtime C ont été introduites. Bien que les anciennes versions non sécurisées soient toujours disponibles, nous vous recommandons de modifier votre code pour utiliser les versions sécurisées. Le compilateur émet un avertissement pour l’utilisation des versions non sécurisées. Vous pouvez choisir de désactiver ou d’ignorer ces avertissements. Pour désactiver l’avertissement pour tous les projets dans votre solution, ouvrez View (Afficher)>Gestionnaire de propriétés, sélectionnez tous les projets pour lesquels vous souhaitez désactiver l’avertissement, puis cliquez avec le bouton droit sur les éléments sélectionnés et choisissez Propriétés. Dans la boîte de dialogue Pages de propriétés sous Propriétés de configuration>C/C++>Avancé, Sélectionnez Désactivation des avertissements spécifiques. Choisissez la flèche déroulante, puis choisissez Modifier. Entrez 4996 dans la zone de texte. (N’incluez pas le préfixe « C ». Pour plus d’informations, consultez Portage pour utiliser secure CRT.

Erreurs provoquées par les modifications apportées aux API Windows ou aux kits SDK obsolètes

Au fil des années, des API Windows et des types de données ont été ajoutés, et parfois modifiés ou supprimés. En outre, d’autres kits SDK qui n’appartiennent pas au système d’exploitation principal sont venus et sont partis. Les programmes plus anciens peuvent contenir des appels aux API qui n’existent plus. Ils peuvent également contenir des appels aux API dans d’autres sdk Microsoft qui ne sont plus pris en charge. Vous pouvez voir des erreurs concernant les API windows manquantes ou les API provenant de sdk Microsoft plus anciens. Il est possible que les API aient été supprimées ou remplacées par des fonctions plus récentes et plus sécurisées.

La documentation de l’API Windows répertorie les systèmes d’exploitation minimum ou maximum pris en charge. Pour plus d’informations sur une API Windows spécifique, recherchez-la dans l’index d’API pour les applications Windows de bureau.

Version de Windows

Lors de la mise à niveau d’un programme qui utilise l’API Windows directement ou indirectement, vous devez décider de la version minimale de Windows à prendre en charge. Dans la plupart des cas, Windows 7 représente un choix judicieux. Pour plus d’informations, consultez Problèmes liés aux fichiers d’en-tête. La macro WINVER définit la plus ancienne version de Windows sur laquelle votre programme est conçu pour s’exécuter. Si votre programme MFC a WINVER la valeur 0x0501 (Windows XP), vous recevez un avertissement, car MFC ne prend plus en charge XP, même si l’ensemble d’outils du compilateur lui-même a un mode XP. La prise en charge de l’ensemble d’outils du compilateur pour Windows XP s’est terminée dans Visual Studio 2017.

Pour plus d’informations, consultez Mise à jour de la version de windows cible et fichiers d’en-tête plus obsolètes.

ATL / MFC

ATL et MFC sont des API relativement stables, mais qui sont parfois modifiées. Pour plus d’informations, consultez l’historique des modifications Visual C++ 2003 - 2015, Nouveautés de Visual C++ dans Visual Studio et améliorations de la conformité C++ dans Visual Studio.

LNK 2005 _DllMain@12 déjà défini dans MSVCRTD.lib

Cette erreur peut se produire dans les applications MFC. Elle indique un problème d’ordre incorrect entre la bibliothèque CRT et la bibliothèque MFC. MFC doit d’abord être lié pour qu’il fournisse new et delete les opérateurs. Pour corriger l’erreur, utilisez le /NODEFAULTLIB commutateur pour ignorer ces bibliothèques par défaut : MSVCRTD.lib et mfcs140d.lib. Ajoutez ensuite ces mêmes bibliothèques que les dépendances supplémentaires.

32 bits et 64 bits

Si votre code d’origine est compilé pour les systèmes 32 bits, vous avez la possibilité de créer une version 64 bits au lieu de (ou en plus) d’une nouvelle application 32 bits. En général, vous devez d’abord lancer la compilation de votre programme en mode 32 bits, puis essayer en mode 64 bits. La compilation en mode 64 bits est simple, mais peut révéler dans certains cas des bogues qui étaient masqués par les builds 32 bits.

En outre, vous devez connaître les éventuels problèmes de compilation et d’exécution liés à la taille du pointeur, aux valeurs d’heure et de taille, ainsi qu’aux spécificateurs de format spécifiques à la taille dans et scanf aux printf fonctions. Pour plus d’informations, consultez Configurer Visual C++ pour les cibles 64 bits, les cibles x64 et les problèmes courants de migration visual C++ 64 bits. Pour plus d’informations sur la migration, consultez le guide de programmation pour Windows 64 bits.

Unicode et MBCS/ASCII

Avant la normalisation d’Unicode, de nombreux programmes utilisaient le jeu de caractères multioctets (MBCS) pour représenter des caractères qui n’étaient pas inclus dans le jeu de caractères ASCII. Dans les anciens projets MFC, MBCS était le paramètre par défaut. Lorsque vous mettez à niveau un tel programme, vous verrez des avertissements qui vous conseillent d’utiliser Unicode à la place. Si vous décidez que la conversion en Unicode ne vaut pas le coût de développement, vous pouvez choisir de désactiver ou d’ignorer l’avertissement. Pour le désactiver pour tous les projets dans votre solution, ouvrez View (Afficher)>Gestionnaire de propriétés, sélectionnez tous les projets pour lesquels vous souhaitez désactiver l’avertissement, puis cliquez avec le bouton droit sur les éléments sélectionnés et choisissez Propriétés. Dans la boîte de dialogue Pages de propriétés, sélectionnez Propriétés de configuration>C/C++>Avancé. Dans la propriété Désactivation des avertissements spécifiques, ouvrez la flèche déroulante, puis choisissez Modifier. Entrez 4996 dans la zone de texte. (N’incluez pas le préfixe « C ». Choisissez OK pour enregistrer la propriété, puis choisissez OK pour enregistrer vos modifications.

Pour plus d’informations, consultez Portage de MBCS vers Unicode. Pour obtenir des informations générales sur MBCS et Unicode, consultez Text and Strings in Visual C++ et Internationalization .

Voir aussi

Mise à niveau de projets à partir de versions antérieures de Visual C++
Améliorations de la conformité de C++ dans Visual Studio