Overzicht van mogelijke upgradeproblemen (Microsoft C++)

In de loop der jaren heeft de Microsoft C++ (MSVC)-compiler veel wijzigingen ondergaan, samen met wijzigingen in de C++-taal zelf, de C++ Standard Library (STL), de C Runtime (CRT) en andere bibliotheken zoals MFC en ATL. Als u een toepassing upgradet van een eerdere versie van Visual Studio, ziet u mogelijk compiler- en linkerfouten en waarschuwingen in code die eerder correct zijn gecompileerd. Hoe ouder de oorspronkelijke codebasis, hoe groter het potentieel voor dergelijke fouten. Dit overzicht bevat een overzicht van de meest voorkomende klassen problemen die u waarschijnlijk zult zien en bevat koppelingen naar meer gedetailleerde informatie.

Opmerking

In het verleden hebben we aanbevolen dat upgrades die meerdere versies van Visual Studio omvatten, incrementeel één versie tegelijk moeten worden uitgevoerd. We raden deze aanpak niet meer aan. We hebben vastgesteld dat het bijna altijd eenvoudiger is om een upgrade uit te voeren naar de meest recente versie van Visual Studio, ongeacht hoe oud de codebasis is.

Vragen of opmerkingen over het upgradeproces kunnen worden verzonden naar vcupgrade@microsoft.com.

Afhankelijkheden van bibliotheek- en buildhulpprogramma's

Opmerking

Deze sectie is van toepassing op toepassingen en bibliotheken die zijn gebouwd met Visual Studio 2013 en eerder. De buildhulpprogramma's die worden gebruikt in Visual Studio 2015, Visual Studio 2017 en Visual Studio 2019 zijn binair compatibel. Zie C++ Binaire compatibiliteit tussen Visual Studio-versies voor meer informatie.

Wanneer u een app bijwerken vanuit Visual Studio 2013 of eerder naar een nieuwere versie, is het vaak raadzaam en noodzakelijk om alle bibliotheken en DLL's te upgraden waarnaar de app is gekoppeld. U moet toegang hebben tot de broncode of de leverancier van de bibliotheek moet nieuwe binaire bestanden opgeven die zijn gecompileerd met dezelfde primaire versie van de compiler. Als aan een van deze voorwaarden wordt voldaan, kunt u deze sectie overslaan, die betrekking heeft op de details van binaire compatibiliteit. Als dat niet het geval is, werken de bibliotheken mogelijk niet in uw bijgewerkte app. De informatie in deze sectie helpt u te begrijpen of u kunt doorgaan met de upgrade.

Bouwhulpmiddelen

De .obj en .lib bestandsindelingen zijn goed gedefinieerd en veranderen zelden. Soms worden er toevoegingen aangebracht aan deze bestandsindelingen, maar deze toevoegingen hebben meestal geen invloed op de mogelijkheid van nieuwere buildhulpprogramma's om objectbestanden en bibliotheken te gebruiken die worden geproduceerd door oudere buildhulpprogramma's. De belangrijkste uitzondering is als u compileert met /GL (Whole Program Optimization). Als u compileert met behulp van /GL, kunt u alleen het resulterende objectbestand koppelen met behulp van dezelfde buildtools die zijn gebruikt om het te maken. Dus als u een objectbestand maakt met /GL en een Visual Studio 2017-compiler (v141) gebruikt, moet u dit koppelen met behulp van de Visual Studio 2017-linker (v141). Dit komt doordat de interne gegevensstructuren binnen de objectbestanden niet stabiel zijn in primaire versies van de buildhulpprogramma's. Nieuwere buildhulpprogramma's begrijpen de oudere gegevensindelingen niet.

C++ heeft geen stabiele toepassingsbinaire interface (ABI). Maar Visual Studio onderhoudt een stabiele C++ ABI voor alle secundaire versies van een release. Visual Studio 2015 (v140), Visual Studio 2017 (v141), Visual Studio 2019 (v142), Visual Studio 2022 (v143) en Visual Studio 2026 (v145) hebben alleen verschillen in hun miniversie. Ze hebben allemaal hetzelfde primaire versienummer, dat 14 is. Zie C++ Binaire compatibiliteit tussen Visual Studio-versies voor meer informatie.

Als u een objectbestand hebt met externe symbolen met C++-koppeling, kan dat objectbestand mogelijk niet correct worden gekoppeld aan objectbestanden die zijn geproduceerd door een andere primaire versie van de buildhulpprogramma's. Er zijn veel mogelijke resultaten: de koppeling kan volledig mislukken (bijvoorbeeld als de naamversiering is gewijzigd). De koppeling zou kunnen slagen, maar de app zou kunnen mislukken bij uitvoering (bijvoorbeeld als de indelingen van typen zijn gewijzigd). Of uw app blijft werken en er gaat niets mis. Let ook op: hoewel de C++ ABI niet stabiel is, zijn de C ABI en de subset van de C++ ABI die vereist is voor COM stabiel.

Als u een koppeling maakt naar een importbibliotheek, kan een latere versie van de Herdistribueerbare Bibliotheken van Visual Studio die ABI-compatibiliteit behouden, tijdens runtime worden gebruikt. Als u uw app bijvoorbeeld compileert en koppelt met behulp van de buildhulpprogramma's van Visual Studio 2015 Update 3, kunt u elke latere redistributable gebruiken. Dat komt doordat de bibliotheken van 2015, 2017, 2019, 2022 en 2026 hun binaire compatibiliteit met eerdere versies hebben behouden. Het omgekeerde is niet waar: u kunt geen herdistribueerbare versie gebruiken voor een eerdere versie van de buildhulpprogramma's dan u hebt gebruikt om een onderdeel van uw code te bouwen.

Bibliotheken

Als u #include een bepaalde versie van de headerbestanden gebruikt, moet u het resulterende objectbestand koppelen aan dezelfde versie van de bibliotheken. Als uw bronbestand bijvoorbeeld Visual Studio 2015 Update 3 <immintrin.h>bevat, moet u een koppeling maken met de Visual Studio 2015 Update 3-bibliotheek vcruntime . Als uw bronbestand ook de Visual Studio 2017 versie 15.5 <iostream>bevat, moet u een koppeling maken met de Visual Studio 2017-versie 15.5 Standard C++-bibliotheek. msvcprt Mixen en vergelijken wordt niet ondersteund.

Voor de Microsoft C++ Standard Library (STL) is mixen-en-matchen expliciet verboden door het gebruik van #pragma detect_mismatch in de standaardheaders sinds Microsoft Visual Studio 2010. Als u niet-compatibele objectbestanden probeert te koppelen of als u een koppeling met de verkeerde standaardbibliotheek hebt, mislukt de koppeling.

Oudere CRT-versie mix-and-matching werd nooit ondersteund, maar het werkte vaak gewoon omdat het API-oppervlak na verloop van tijd niet veel veranderde. De universele CRT heeft achterwaartse compatibiliteit verbroken, zodat we in de toekomst achterwaartse compatibiliteit kunnen behouden. In de toekomst hebben we geen plannen om nieuwe, versiegebonden Universal CRT-binaries te introduceren. In plaats daarvan wordt de bestaande Universele CRT nu ter plaatse bijgewerkt.

Voor gedeeltelijke koppelingscompatibiliteit met objectbestanden (en bibliotheken) die zijn gecompileerd met oudere versies van de Microsoft C Runtime-headers, bieden we een bibliotheek, legacy_stdio_definitions.libmet Visual Studio 2015 en hoger. Deze bibliotheek biedt compatibiliteitssymbolen voor de meeste functies en gegevensexports die zijn verwijderd uit de Universele CRT. De set compatibiliteitssymbolen, geleverd door legacy_stdio_definitions.lib, is geschikt om te voldoen aan de meeste afhankelijkheden, inclusief alle afhankelijkheden in bibliotheken die in de Windows SDK zijn opgenomen. Sommige symbolen zijn echter verwijderd uit de Universele CRT die geen compatibiliteitssymbolen hebben. Deze symbolen bevatten zowel bepaalde functies (bijvoorbeeld __iob_func) als sommige gegevensexports (bijvoorbeeld __imp___iob, __imp___pctype). __imp___mb_cur_max

Als u een statische bibliotheek hebt gebouwd met een oudere versie van de C Runtime-headers, raden we de volgende acties aan in deze volgorde:

1. Bouw de statische bibliotheek opnieuw met behulp van de nieuwe versie van Visual Studio en de Universal CRT-headers ter ondersteuning van het koppelen met de Universele CRT. Deze benadering wordt volledig ondersteund en de beste optie.

2. Als u de statische bibliotheek niet (of niet wilt) herbouwen, kunt u proberen een koppeling te maken met legacy_stdio_definitions.lib. Als deze voldoet aan de afhankelijkheden van de koppelingstijd van uw statische bibliotheek, moet u de statische bibliotheek grondig testen zoals deze wordt gebruikt in het binaire bestand. Zorg ervoor dat het niet nadelig wordt beïnvloed door een van de gedragswijzigingen die zijn aangebracht in de Universele CRT.

3. Misschien worden de afhankelijkheden van uw statische bibliotheek niet vervuld door legacy_stdio_definitions.lib of werkt de bibliotheek niet met de Universele CRT vanwege gedragswijzigingen. In dit geval wordt u aangeraden uw statische bibliotheek in te kapselen in een DLL die u koppelt aan de vereiste versie van Microsoft C Runtime. Als de statische bibliotheek bijvoorbeeld is gebouwd met Visual Studio 2013, bouwt u deze DLL met behulp van de buildhulpprogramma's van Visual Studio 2013 en C++-bibliotheken. Door de bibliotheek in een DLL te bouwen, kunt u de implementatiedetails inkapselen die afhankelijk zijn van een bepaalde versie van Microsoft C Runtime. Let op dat de DLL-interface geen details prijsgeeft over welke C Runtime wordt gebruikt. Dit kan bijvoorbeeld gebeuren als deze een FILE* over de DLL-grens retourneert, of als het een aanwijzer teruggeeft die met malloc is toegewezen en die de aanroeper moet free.

Het gebruik van meerdere CRT's in één proces is niet op zichzelf problematisch. (In feite laden de meeste processen meerdere CRT-DLL's. Onderdelen van het Windows-besturingssysteem zijn bijvoorbeeld afhankelijk van msvcrt.dll, en de CLR is afhankelijk van zijn eigen privé-CRT.) Er treden problemen op wanneer u de status van verschillende CRT's door elkaar haalt. U moet bijvoorbeeld geen geheugen toewijzen met behulp van msvcr110.dll!malloc en dat geheugen vrijmaken met behulp van msvcr120.dll!free, en u moet geen bestand openen met behulp van msvcr110!fopen en proberen te lezen uit dat bestand met behulp van msvcr120!fread. Zolang u de toestand niet van verschillende CRT's verwart, kunt u veilig meerdere CRT's in één proces laden.

Zie Uw code upgraden naar universal CRT voor meer informatie.

Fouten veroorzaakt door projectinstellingen

Als u het upgradeproces wilt starten, opent u een ouder project/oplossing/werkruimte in de nieuwste versie van Visual Studio. Visual Studio maakt een nieuw project op basis van de oude projectinstellingen. Controleer of het oudere project bibliotheekpaden bevat of paden bevat die zijn vastgelegd in niet-standaardlocaties. Het is mogelijk dat de bestanden in deze paden niet zichtbaar zijn voor de compiler wanneer het project de standaardinstellingen gebruikt. Zie de instelling Linker OutputFile voor meer informatie.

Over het algemeen is het nu een goed moment om uw projectcode te organiseren om het onderhoud van projecten te vereenvoudigen en uw bijgewerkte code zo snel mogelijk te bouwen. Als uw broncode al goed is georganiseerd en uw oudere project wordt gecompileerd onder Visual Studio 2010 of hoger, kunt u het nieuwe projectbestand handmatig bewerken ter ondersteuning van compilatie op zowel de oude als de nieuwe compiler. In het volgende voorbeeld ziet u hoe u compileert voor zowel Visual Studio 2015 als Visual Studio 2017:

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

LNK2019: Niet-opgelost extern

Voor niet-opgeloste symbolen moet u mogelijk uw projectinstellingen herstellen.

• Als het bronbestand zich op een niet-standaardlocatie bevindt, hebt u het pad toegevoegd aan de mappen van het project?

• Als het externe bestand is gedefinieerd in een .lib bestand, hebt u het lib-pad opgegeven in de projecteigenschappen en is dit de juiste versie van het .lib bestand dat zich daar bevindt?

• Probeert u een koppeling te maken naar een .lib bestand dat is gecompileerd met een andere versie van Visual Studio? nl-NL: Als dit het geval is, raadpleegt u de vorige sectie over afhankelijkheden van bibliotheken en buildtools.

• Komen de typen argumenten op de aanroepsite daadwerkelijk overeen met een bestaande overbelasting van de functie? Controleer of de onderliggende typen zijn wat u verwacht, zowel voor de typedefs in de signatuur van de functie als in de code die de functie aanroept.

Als u onopgeloste symboolfouten wilt oplossen, kunt u de dumpbin.exe symbolen onderzoeken die zijn gedefinieerd in een binair bestand. Probeer de volgende opdrachtregel om symbolen weer te geven die zijn gedefinieerd in een bibliotheek:

dumpbin.exe /LINKERMEMBER somelibrary.lib

/Zc:wchar_t (wchar_t Is een systeemeigen type)

(In Microsoft Visual C++ 6.0 en eerdere versies werd wchar_t niet als een ingebouwd type geïmplementeerd. Het werd in wchar.h gedeclareerd als een typedef voor unsigned short.) De C++-standaard vereist dat wchar_t een ingebouwd type is. Het gebruik van de typedef-versie kan problemen met de draagbaarheid veroorzaken. Als u een upgrade uitvoert van eerdere versies van Visual Studio en de compilerfout C2664 ziet omdat de code impliciet een wchar_tunsigned shortconversie naar probeert uit te voeren, raden we u aan de code te wijzigen om de fout op te lossen in plaats van de instelling /Zc:wchar_t-. Zie (wchar_t is systeemeigen type) voor/Zc:wchar_t meer informatie.

Upgraden met de linkeropties /NODEFAULTLIB, /ENTRY, en /NOENTRY

Met de /NODEFAULTLIB linkeroptie (of de linker-eigenschap Alle standaardbibliotheken negeren) wordt de linker verteld niet automatisch de standaardbibliotheken zoals de CRT te koppelen. Dit betekent dat elke bibliotheek afzonderlijk als invoer moet worden vermeld. Deze lijst met bibliotheken wordt gegeven in de eigenschap Aanvullende afhankelijkheden in de sectie Linker van het dialoogvenster Projecteigenschappen .

Projecten die deze optie gebruiken, geven een probleem bij het upgraden, omdat de inhoud van sommige van de standaardbibliotheken is geherstructureerd. Omdat elke bibliotheek moet worden vermeld in de eigenschap Aanvullende afhankelijkheden of op de opdrachtregel van de linker, moet u de lijst met bibliotheken bijwerken om alle huidige namen te kunnen gebruiken.

In de volgende tabel ziet u de bibliotheken waarvan de inhoud is gewijzigd vanaf Visual Studio 2015. Als u een upgrade wilt uitvoeren, moet u de nieuwe bibliotheeknamen in de tweede kolom toevoegen aan de bibliotheken in de eerste kolom. Sommige van deze bibliotheken zijn importbibliotheken, maar dat maakt niet uit.

Als u het volgende gebruikt:	U moet deze bibliotheken gebruiken:
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

Hetzelfde probleem geldt ook als u de /ENTRY optie of de /NOENTRY optie gebruikt, die ook het effect heeft van het omzeilen van de standaardbibliotheken.

Fouten veroorzaakt door verbeterde taalconformantie

De Microsoft C++-compiler heeft de conformiteit van de C++-standaard in de loop der jaren voortdurend verbeterd. Code die in eerdere versies is gecompileerd, kan niet worden gecompileerd in latere versies van Visual Studio. Dat komt doordat de compiler een fout markeert die eerder is genegeerd of expliciet is toegestaan.

De /Zc:forScope switch werd bijvoorbeeld vroeg in de geschiedenis van MSVC geïntroduceerd. Het maakt niet-conform gedrag mogelijk voor lusvariabelen. Deze switch is nu afgeschaft en kan in toekomstige versies worden verwijderd. We raden u ten zeerste aan deze switch niet te gebruiken bij het upgraden van uw code. Zie voor meer informatie /Zc:forScope- is afgeschaft.

Een voorbeeld van een veelvoorkomende compilerfout die u kunt zien wanneer een upgrade wordt uitgevoerd, is wanneer een niet-const-argument wordt doorgegeven aan een const-parameter. Oudere versies van de compiler markeerden dit niet altijd als een fout. Zie de striktere conversies van de compiler voor meer informatie.

Voor meer informatie over specifieke verbeteringen in overeenstemming, zie Visual C++ wijzigingsgeschiedenis 2003 - 2015 en C++ conformiteitsverbeteringen in Visual Studio.

Fouten met <stdint.h> integrale typen

De <stdint.h> header definieert typedefs en macro's die, in tegenstelling tot ingebouwde integrale typen, gegarandeerd een opgegeven lengte hebben op alle platforms. Enkele voorbeelden zijn uint32_t en int64_t. De <stdint.h> header is toegevoegd in Visual Studio 2010. Code die vóór 2010 is geschreven, heeft mogelijk privédefinities voor deze typen opgegeven. En deze definities zijn mogelijk niet altijd consistent met de <stdint.h> definities.

Als de fout C2371 is en er een stdint type bij betrokken is, betekent dit waarschijnlijk dat het type is gedefinieerd in een header in uw code of een bibliotheekbestand van derden. Wanneer u een upgrade uitvoert, moet u aangepaste definities van <stdint.h> typen elimineren, maar eerst de aangepaste definities vergelijken met de huidige standaarddefinities om ervoor te zorgen dat u geen nieuwe problemen introduceert.

U kunt op F12 (Naar definitie gaan) drukken om te zien waar het type in kwestie is gedefinieerd.

De /showIncludes compileroptie kan hier nuttig zijn. Selecteer in het dialoogvenster Eigenschappenpagina's voor uw project de pagina Configuratie-eigenschappen>C/C++>Geavanceerd en stel Opnemen weergeven in op Ja. Bouw vervolgens uw project opnieuw op. U ziet de lijst #include met bestanden in het uitvoervenster. Elke koptekst wordt ingesprongen onder de bovenliggende koptekst die deze omvat.

Fouten betreffende CRT-functies

Er zijn in de loop der jaren veel wijzigingen aangebracht in de C-runtime. Er zijn veel beveiligde versies van functies toegevoegd en sommige zijn verwijderd. Zoals eerder in dit artikel is beschreven, is de implementatie van de CRT in Visual Studio 2015 geherstructureerd in nieuwe binaire bestanden en bijbehorende .lib bestanden.

Als een fout betrekking heeft op een CRT-functie, zoekt u de wijzigingsgeschiedenis van Visual C++ 2003 - 2015 of C++ in Visual Studio om te zien of deze artikelen aanvullende informatie bevatten. Als de fout is LNK2019, controleert u of de functie niet is verwijderd. Als u er anders zeker van bent dat de functie nog bestaat en de aanroepende code juist is, controleer dan of uw project gebruikmaakt van /NODEFAULTLIB. Zo ja, dan moet u de lijst met bibliotheken bijwerken voor het gebruik van de nieuwe universele (UCRT)-bibliotheken. Zie de sectie hierboven over bibliotheek en afhankelijkheden voor meer informatie.

Als de fout betrekking heeft op printf of scanf, moet u ervoor zorgen dat u geen van beide functies zelf definieert zonder stdio.h. Als dat het geval is, verwijdert u de privédefinities of koppelt u aan legacy_stdio_definitions.lib. U kunt deze bibliotheek instellen in het dialoogvenster Eigenschappenpagina's onder Configuratie-eigenschappen>Linker>Invoer, in de eigenschap Aanvullende afhankelijkheden. Als u een koppeling met Windows SDK 8.1 of eerder hebt, voegt u dit toe legacy_stdio_definitions.lib.

Als de fout argumenten voor tekenreeksopmaak omvat, komt dit waarschijnlijk doordat de compiler strenger is in het handhaven van de standaard. Zie de wijzigingsgeschiedenis voor meer informatie. Let hier goed op eventuele fouten, omdat ze mogelijk een beveiligingsrisico kunnen vertegenwoordigen.

Fouten veroorzaakt door wijzigingen in de C++-standaard

De C++-standaard zelf is ontwikkeld op manieren die niet altijd compatibel zijn met eerdere versies. C++11 heeft semantiek, nieuwe trefwoorden en andere taal- en standaardbibliotheekfuncties geïntroduceerd. Deze wijzigingen kunnen mogelijk compilerfouten en zelfs ander runtimegedrag veroorzaken.

Een oud C++-programma kan bijvoorbeeld de iostream.h header bevatten. Deze header is vroeg in de geschiedenis van C++ afgeschaft en is uiteindelijk volledig verwijderd uit Visual Studio. In dit geval moet u <iostream> gebruiken en uw code herschrijven. Zie Oude code bijwerken iostreamvoor meer informatie.

C4838: waarschuwing voor narrowing conversie

De C++-standaard geeft nu aan dat conversies van niet-ondertekende integrale waarden de conversies beperken. De compiler heeft deze waarschuwing niet voor Visual Studio 2015 weergegeven. Inspecteer elk voorval om te verzekeren dat de versmalling geen invloed heeft op de juistheid van uw code.

Waarschuwingen voor het gebruik van beveiligde CRT-functies

In de loop der jaren zijn beveiligde versies van C Runtime-functies geïntroduceerd. Hoewel de oude, niet-beveiligde versies nog steeds beschikbaar zijn, is het raadzaam om uw code te wijzigen om de beveiligde versies te gebruiken. De compiler geeft een waarschuwing voor het gebruik van de niet-beveiligde versies. U kunt deze waarschuwingen uitschakelen of negeren. Als u de waarschuwing voor alle projecten in uw oplossing wilt uitschakelen, opent uEigenschapsbeheer>, selecteert u alle projecten waarvoor u de waarschuwing wilt uitschakelen en klikt u met de rechtermuisknop op de geselecteerde items en kiest u Eigenschappen. Selecteer in het dialoogvenster Eigenschappenpagina's onder Configuratie-eigenschappen>C/C++>Geavanceerd de optie Specifieke waarschuwingen uitschakelen. Kies de vervolgkeuzepijl en kies Bewerken. Voer 4996 in het tekstvak in. (Neem het voorvoegsel 'C' niet op.) Zie Porteren voor gebruik van de Secure CRT voor meer informatie.

Fouten veroorzaakt door wijzigingen in Windows-API's of verouderde SDK's

In de loop der jaren zijn Windows-API's en gegevenstypen toegevoegd en soms gewijzigd of verwijderd. Andere SDK's die niet tot het kernbesturingssysteem behoren, zijn ook gekomen en verdwenen. Oudere programma's bevatten mogelijk aanroepen naar API's die niet meer bestaan. Ze kunnen ook aanroepen naar API's bevatten in andere Microsoft SDK's die niet meer worden ondersteund. U kunt fouten zien over ontbrekende Windows-API's of API's van oudere Microsoft SDK's. Het is mogelijk dat de API's zijn verwijderd of vervangen door nieuwere, veiligere functies.

Windows API-documentatie bevat de minimaal of maximaal ondersteunde besturingssystemen. Voor informatie over een specifieke Windows-API zoekt u deze op in de API-index voor bureaublad-Windows-toepassingen.

Windows-versie

Wanneer u een programma upgradet dat rechtstreeks of indirect gebruikmaakt van de Windows-API, moet u de minimale Windows-versie bepalen die moet worden ondersteund. In de meeste gevallen is Windows 7 een goede keuze. Zie Problemen met headerbestanden voor meer informatie. De WINVER macro definieert de oudste versie van Windows waarop uw programma is ontworpen om te worden uitgevoerd. Als uw MFC-programma is ingesteld WINVER op 0x0501 (Windows XP) krijgt u een waarschuwing omdat MFC XP niet meer ondersteunt, zelfs als de buildhulpprogramma's een XP-modus hebben. Ondersteuning voor buildhulpprogramma's voor Windows XP is beëindigd in Visual Studio 2017 en ondersteuning voor Windows 7, 8.0 en 8.1 is beëindigd in Visual Studio 2026.

Zie De doelversie van Windows enverouderde headerbestanden bijwerken voor meer informatie.

ATL / MFC

ATL en MFC zijn relatief stabiele API's, maar er worden af en toe wijzigingen aangebracht. Zie Visual C++ wijzigingsgeschiedenis 2003 - 2015, Wat is er nieuw voor Visual C++ in Visual Studio en verbeteringen in de naleving van C++ in Visual Studio.

LNK 2005-_DllMain@12 al gedefinieerd in MSVCRTD.lib

Deze fout kan optreden in MFC-toepassingen. Het geeft een bestelprobleem aan tussen de CRT-bibliotheek en de MFC-bibliotheek. MFC moet eerst worden gekoppeld zodat het new en delete Operators levert. Als u de fout wilt oplossen, gebruikt u de /NODEFAULTLIB schakeloptie om deze standaardbibliotheken te negeren: MSVCRTD.lib en mfcs140d.lib. Voeg vervolgens dezelfde bibliotheken toe als extra afhankelijkheden.

32 versus 64-bits

Als uw oorspronkelijke code is gecompileerd voor 32-bits systemen, hebt u de mogelijkheid om een 64-bits versie te maken in plaats van (of naast) een nieuwe 32-bits app. Over het algemeen moet u eerst uw programma compileren in de 32-bits modus en vervolgens proberen 64-bits. Compileren voor 64-bits is eenvoudig, maar in sommige gevallen kan het fouten onthullen die zijn verborgen door 32-bits builds.

U moet ook rekening houden met mogelijke problemen met compileertijd en runtime met betrekking tot aanwijzergrootte, tijd- en groottewaarden en groottespecifieke notatieaanduidingen in printf en scanf functies. Zie Microsoft C++ configureren voor 64-bits, x64-doelen en veelvoorkomende 64-bits migratieproblemen met Microsoft C++ voor meer informatie. Zie de programmeerhandleiding voor 64-bits Windows voor meer migratietips.

Unicode versus MBCS/ASCII

Voordat Unicode werd gestandaardiseerde, gebruikten veel programma's de Multibyte Character Set (MBCS) om tekens weer te geven die niet zijn opgenomen in de ASCII-tekenset. In oudere MFC-projecten was MBCS de standaardinstelling. Wanneer u een upgrade van een dergelijk programma uitvoert, ziet u in plaats daarvan waarschuwingen die adviseren unicode te gebruiken. Als u besluit dat de conversie naar Unicode de ontwikkelingskosten niet waard is, kunt u ervoor kiezen om de waarschuwing uit te schakelen of te negeren. Als u dit wilt uitschakelen voor alle projecten in uw oplossing, opent uEigenschapsbeheer>, selecteert u alle projecten waarvoor u de waarschuwing wilt uitschakelen, klikt u met de rechtermuisknop op de geselecteerde items en kiest u Eigenschappen. Selecteer in het dialoogvenster Eigenschappenpagina'sconfiguratie-eigenschappen>C/C++>Geavanceerd. Open in de eigenschap Specifieke waarschuwingen uitschakelen de vervolgkeuzepijl en kies Bewerken. Voer 4996 in het tekstvak in. (Neem het voorvoegsel 'C' niet op.) Kies OK om de eigenschap op te slaan en kies vervolgens OK om uw wijzigingen op te slaan.

Zie Porting from MBCS to Unicode (Overzetten van MBCS naar Unicode) voor meer informatie. Zie Tekst en tekenreeksen in Microsoft C++ en Internationalisatie voor algemene informatie over MBCS versus Unicode.

Zie ook

Projecten upgraden van eerdere versies van Microsoft C++
verbeteringen van de C++-conformiteit in Visual Studio