A lehetséges frissítési problémák áttekintése (Microsoft C++)

Az évek során a Microsoft C++ (MSVC) fordítója számos változáson ment keresztül, a C++ nyelv, a C++ Standard Könyvtár (STL), a C futtatókörnyezet (CRT) és más kódtárak, például az MFC és az ATL változásaival együtt. Ennek eredményeképpen, amikor frissít egy alkalmazást a Visual Studio egy korábbi verziójáról, fordítói és linkerhibák és figyelmeztetések jelenhetnek meg a korábban tisztán lefordított kódban. Minél régebbi az eredeti kódbázis, annál nagyobb az ilyen hibák lehetősége. Ez az áttekintés összefoglalja a leggyakrabban előforduló problémák osztályait, és részletesebb információkra mutató hivatkozásokat tartalmaz.

Megjegyzés:

Korábban azt javasoltuk, hogy a Visual Studio több verziójára kiterjedő frissítéseket egyszerre csak egy verzióban hajtsuk végre. Ezt a megközelítést már nem javasoljuk. Megállapítottuk, hogy szinte mindig egyszerűbb a Visual Studio legújabb verziójára frissíteni, függetlenül attól, hogy a kódbázis hány éves.

A frissítési folyamatra vonatkozó kérdéseket vagy megjegyzéseket elküldheti a következő címre vcupgrade@microsoft.com: .

Könyvtári és build eszközök függőségei

Megjegyzés:

Ez a szakasz a Visual Studio 2013-as és korábbi verzióival készült alkalmazásokra és kódtárakra vonatkozik. A Visual Studio 2015-ben, a Visual Studio 2017-ben és a Visual Studio 2019-ben használt buildeszközök binárisan kompatibilisek. További információ: C++ Bináris kompatibilitás a Visual Studio-verziók között.

Ha egy alkalmazást a Visual Studio 2013-ról vagy egy újabb verzióra frissít, gyakran tanácsos és szükséges is frissíteni az alkalmazás hivatkozásait az összes kódtárra és DLL-re. Vagy hozzáféréssel kell rendelkeznie a forráskódhoz, vagy a kódtár szállítójának új bináris fájlokat kell biztosítania, amelyek a fordító ugyanazon főverziójával vannak lefordítva. Ha az egyik feltétel igaz, akkor kihagyhatja ezt a szakaszt, amely a bináris kompatibilitás részleteivel foglalkozik. Ha ez sem így van, akkor előfordulhat, hogy a kódtárak nem működnek a frissített alkalmazásban. Az ebben a szakaszban található információk segítenek megérteni, hogy folytathatja-e a frissítést.

Építőeszközök

A .obj és .lib fájlformátumok jól definiáltak és ritkán változnak. Néha ezekhez a fájlformátumokhoz adnak hozzá kiegészítéseket, de ezek a kiegészítések általában nem befolyásolják az újabb buildeszközök azon képességét, hogy a régebbi buildelési eszközök által létrehozott objektumfájlokat és kódtárakat használják. A fő kivétel az, ha a fordítás a Teljes programoptimalizálás (Whole Program Optimization) használatával/GL történik. Ha a fordításhoz /GL-t használ, az eredményként kapott objektumfájlt csak az előállítására használt építőeszközökkel kapcsolhatja össze. Ha tehát egy Visual Studio 2017 (v141) fordítóval /GL hoz létre egy objektumfájlt, akkor a Visual Studio 2017 (v141) linkerrel kell azt összekapcsolnia. Ennek az az oka, hogy az objektumfájlok belső adatstruktúrái nem stabilak a buildelési eszközök fő verzióiban. Az újabb buildelési eszközök nem értik a régebbi adatformátumokat.

A C++ nem rendelkezik stabil alkalmazás bináris adapterrel (ABI). A Visual Studio azonban stabil C++ ABI-t tart fenn a kiadás összes alverziójához. A Visual Studio 2015 (v140), a Visual Studio 2017 (v141), a Visual Studio 2019 (v142), a Visual Studio 2022 (v143) és a Visual Studio 2026 (v145) buildelési eszközei csak az alverziójukban változnak. Mindegyiknek ugyanaz a főverziószáma, ami 14. További információ: C++ Bináris kompatibilitás a Visual Studio-verziók között.

Ha olyan objektumfájllal rendelkezik, amely C++ kapcsolattal rendelkezik külső szimbólumokkal, előfordulhat, hogy az objektumfájl nem kapcsolódik megfelelően a buildelési eszközök egy másik főverziója által létrehozott objektumfájlokhoz. Számos lehetséges kimenetel lehet: a hivatkozás teljes egészében meghiúsulhat (például ha a névdekoráció megváltozott). A hivatkozás sikeres lehet, de az alkalmazás futásidőben meghiúsulhat (például ha a típuselrendezések módosulnak). Vagy az alkalmazás továbbra is működik, és semmi sem fog rosszul működni. Azt is vegye figyelembe, hogy míg a C++ ABI nem stabil, a C ABI és a COM-hoz szükséges C++ ABI részhalmaza stabil.

Ha importálási kódtárra hivatkozik, a Visual Studio újraterjeszthető kódtárainak bármely olyan későbbi verziója használható, amely megőrzi az ABI-kompatibilitást. Ha például a Visual Studio 2015 Update 3 buildelési eszközeivel fordítja össze és csatolja az alkalmazást, bármely későbbi terjeszthető eszközt használhat. Ennek az az oka, hogy a 2015-ös, 2017-ös, 2019-ös, 2022-s és 2026-os kódtárak megőrizték a visszamenőleges bináris kompatibilitást. A fordítottja nem igaz: A build eszközök egy újabb verziójához nem használhat egy korábbi verziójú újraterjeszthető csomagot, mint amit bármely kódkomponens elkészítéséhez használt.

Könyvtárak

Ha #include a fejlécfájlok egy adott verzióját használja, az eredményként kapott objektumfájlt a kódtárak ugyanazon verziójához kell kapcsolnia. Így például ha a forrásfájl tartalmazza a Visual Studio 2015 Update 3-at <immintrin.h>, akkor a Visual Studio 2015 Update 3 vcruntime kódtárhoz kell kapcsolódnia. Hasonlóképpen, ha a forrásfájl tartalmazza a Visual Studio 2017 15.5-ös <iostream>verzióját, akkor a Visual Studio 2017 15.5-ös standard C++ kódtárához kell kapcsolódnia. msvcprt A keverés nem támogatott.

A Microsoft C++ Standard Library (STL) esetében a mixing-and-matching használatát kifejezetten letiltották a standard fejlécekben a Visual Studio 2010 óta, #pragma detect_mismatch alkalmazásával. Ha nem kompatibilis objektumfájlokat próbál összekapcsolni, vagy ha nem a megfelelő szabványos tárral kapcsolódik, a hivatkozás sikertelen lesz.

A régebbi CRT-verziók keverése és egyeztetése soha nem támogatott, de gyakran csak azért működött, mert az API felülete idővel nem változott sokat. Az univerzális CRT tönkretette a visszafelé kompatibilitást annak érdekében, hogy a jövőben fenntarthassuk a visszamenőleges kompatibilitást. Nem tervezzük, hogy a jövőben új, verziószámozott univerzális CRT bináris fájlokat vezetünk be. Ehelyett a meglévő univerzális CRT-t helyben frissítjük.

A Microsoft C futtatókörnyezeti fejléceinek régebbi verzióival lefordított objektumfájlokkal (és könyvtárakkal) való részleges hivatkozási kompatibilitás biztosítása érdekében egy legacy_stdio_definitions.lib könyvtárat biztosítunk a Visual Studio 2015-höz és újabb verziókhoz. Ez a kódtár kompatibilitási szimbólumokat biztosít az univerzális CRT-ből eltávolított függvények és adatexportálások többségéhez. A kompatibilitási szimbólumok által legacy_stdio_definitions.lib biztosított halmaz elegendő a legtöbb függőség kielégítéséhez, beleértve a Windows SDK-ban található kódtárakban található összes függőséget is. Egyes szimbólumok azonban el lettek távolítva az univerzális CRT-ből, amelyek nem rendelkeznek kompatibilitási szimbólumokkal. Ezek a szimbólumok egyes függvényeket (például __iob_func) és egyes adatexportálásokat (például , __imp___iob, __imp___pctype) __imp___mb_cur_maxis tartalmaznak.

Ha a C futtatókörnyezet fejléceinek egy régebbi verziójával létrehozott statikus kódtárat használ, a következő műveleteket javasoljuk ebben a sorrendben:

1. Építse újra a statikus kódtárat a Visual Studio új verziójával és az univerzális CRT-fejlécekkel, hogy támogassa az univerzális CRT-hez való kapcsolódást. Ez a megközelítés teljes mértékben támogatott, és a legjobb megoldás.

2. Ha nem tudja (vagy nem szeretné) újraépíteni a statikus tárat, megpróbálkozhat a csatolással legacy_stdio_definitions.lib. Ha megfelel a statikus kódtár kapcsolat-idő függőségeinek, érdemes alaposan tesztelni a statikus kódtárat, ahogy azt a bináris kódtárban használják. Győződjön meg arról, hogy az univerzális CRT-ben végrehajtott viselkedési változások ne okozzanak kárt.

3. Előfordulhat, hogy a statikus kódtár függőségei nem teljesülnek legacy_stdio_definitions.lib , vagy a kódtár nem működik az univerzális CRT-vel a viselkedésváltozások miatt. Ebben az esetben javasoljuk, hogy ágyazza be a statikus kódtárat egy OLYAN DLL-be, amely a Microsoft C futtatókörnyezet szükséges verziójához kapcsolódik. Ha például a statikus kódtár a Visual Studio 2013 használatával készült, akkor ezt a DLL-t a Visual Studio 2013 buildelési eszközeivel és C++ kódtáraival is létrehozhatja. A kódtár DLL-be való létrehozásával beágyazza a Microsoft C futtatókörnyezet egy adott verziójától függő implementáció részleteit. Ügyeljen arra, hogy a DLL interfésze ne árulja el, hogy melyik C-futtatókörnyezetet használja, például ha visszaad egy FILE*-t a DLL határán keresztül, vagy egy malloc-val allokált mutatót, amelyet a hívónak kell free-nie.

A több CRT egyetlen folyamatban való használata önmagában nem problémás. (Valójában a legtöbb folyamat több CRT-DLL-t tölt be. Például a Windows operációs rendszer összetevői függenek msvcrt.dll, a CLR pedig a saját privát CRT-jától függ.) Problémák merülnek fel, ha összekeveri a különböző CRT-k állapotait. Például ne foglaljon le memóriát msvcr110.dll!malloc a segítségével, és ne próbálja meg felszabadítani a memóriát a használatával msvcr120.dll!free, és ne próbáljon meg megnyitni egy FÁJLT a fájl használatával msvcr110!fopen , és ne próbáljon meg olvasni a fájlból a használatával msvcr120!fread. Mindaddig, amíg a különböző CRT-k állapotát nem keveri össze, biztonságosan betölthet több CRT-t egyetlen folyamatba.

További információ: A kód frissítése az univerzális CRT-re.

A projektbeállítások által okozott hibák

A frissítési folyamat megkezdéséhez nyisson meg egy régebbi projektet/megoldást/munkaterületet a Visual Studio legújabb verziójában. A Visual Studio új projektet hoz létre a régi projektbeállítások alapján. Ellenőrizze, hogy a régebbi projekt rendelkezik-e kódtár elérési útokkal, vagy tartalmaz-e olyan elérési utakat, amelyek nem szabványos helyekre vannak beállítva. Előfordulhat, hogy az elérési utak fájljai nem lesznek láthatók a fordító számára, amikor a projekt az alapértelmezett beállításokat használja. További információ: Linker OutputFile beállítás.

Általánosságban elmondható, hogy most nagyszerű alkalom a projektkód rendszerezésére a projektkarbantartás egyszerűsítése és a frissített kód lehető leggyorsabb összeállítása érdekében. Ha a forráskód már jól van rendszerezve, és a régebbi projekt a Visual Studio 2010 vagy újabb verziójában készül, manuálisan szerkesztheti az új projektfájlt, hogy támogassa a fordítást a régi és az új fordítóban is. Az alábbi példa bemutatja, hogyan lehet a Visual Studio 2015 és a Visual Studio 2017 számára kompilálni:

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

LNK2019: Megoldatlan külső

A megoldatlan szimbólumok esetében előfordulhat, hogy javítania kell a projekt beállításait.

• Ha a forrásfájl nem alapértelmezett helyen található, hozzáadta az elérési utat a projekt belefoglalt könyvtáraihoz?

• Ha a külső fájl egy .lib fájlban van definiálva, megadta a lib elérési útját a projekt tulajdonságai között, és a fájl megfelelő verziója .lib található ott?

• Olyan fájlra próbál hivatkozni .lib , amelyet a Visual Studio egy másik verziójával állítottak össze? Ha igen, tekintse meg az előző szakaszt a kódtárról és az eszközök függőségeinek összeállításáról.

• A hívási hely argumentumainak típusai megfelelnek-e a függvény meglévő túlterhelésének? Ellenőrizze, hogy a mögöttes típusok a vártak-e, mind a függvény szignatúrájában lévő típusdefiníciók esetében, mind a függvényt meghívó kódban.

A megoldatlan szimbólumhibák elhárításához használhatja dumpbin.exe a binárisban definiált szimbólumok vizsgálatát. Próbálja ki a következő parancssort a kódtárban definiált szimbólumok megtekintéséhez:

dumpbin.exe /LINKERMEMBER somelibrary.lib

/Zc:wchar_t (wchar_t Natív típus)

A Microsoft Visual C++ 6.0-ban és korábbi verzióiban a wchar_t nem beépített típusként volt implementálva. Typedefként deklarálták a wchar.h-ban a unsigned short számára. A C++ szabvány előírja, hogy a wchar_t-nek beépített típusnak kell lennie. A typedef verzió használata hordozhatósági problémákat okozhat. Ha a Visual Studio korábbi verzióiról frissít, és a C2664 fordítóhiba jelenik meg, mert a kód implicit módon próbál átalakítani egy wchar_t típust unsigned short típusra, akkor azt javasoljuk, hogy inkább módosítsa a kódot a hiba kijavításához, ahelyett hogy a /Zc:wchar_t--t állítaná be. További információkért keresse fel /Zc:wchar_t (wchar_t egy natív típus).

Frissítés a linker beállításaival /NODEFAULTLIB, /ENTRYés /NOENTRY

A /NODEFAULTLIB csatolási beállítás (vagy az Összes alapértelmezett kódtár csatolásának mellőzése tulajdonság) azt jelzi, hogy a hivatkozáskezelő nem kapcsol automatikusan az alapértelmezett kódtárakban, például a CRT-ben. Ez azt jelenti, hogy az egyes kódtárakat külön-külön kell bemenetként listázni. A kódtárak listája a Projekttulajdonságok párbeszédpanel Linker szakaszÁnak További függőségek tulajdonságában található.

Az ezt a lehetőséget használó projektek problémát jelentenek a frissítés során, mivel az alapértelmezett kódtárak némelyikének tartalma újrabontásra került. Mivel minden kódtárnak szerepelnie kell a További függőségek tulajdonságban vagy a linker parancssorában, frissítenie kell a kódtárak listáját az összes aktuális név használatához.

Az alábbi táblázat azokat a kódtárakat mutatja be, amelyek tartalma a Visual Studio 2015-től kezdve módosult. A frissítéshez hozzá kell adnia a második oszlopban lévő új könyvtárneveket az első oszlop könyvtáraihoz. Néhány ilyen kódtár importálási kódtár, de ez nem számít.

Ha a következőt használta:	Ezeket a kódtárakat kell használnia:
libcmt.lib	\, \, \
libcmtd.lib	\, \, \
msvcrt.lib	\, \, \
msvcrtd.lib	\, \, \

Ugyanez a probléma akkor is fennáll, ha a /ENTRY lehetőséget vagy a /NOENTRY beállítást használja, amely szintén az alapértelmezett kódtárak megkerülését eredményezi.

Továbbfejlesztett nyelvkonformitás által okozott hibák

A Microsoft C++ fordító az évek során folyamatosan javította a C++ szabványnak való megfelelést. Előfordulhat, hogy a korábbi verziókban lefordított kód fordítása nem sikerül a Visual Studio későbbi verzióiban. Ennek az az oka, hogy a fordító helyesen jelöl egy hibát, amelyet korábban figyelmen kívül hagyott vagy explicit módon engedélyezett.

Például az /Zc:forScope kapcsolót az MSVC történetének korai szakaszában vezették be. Lehetővé teszi a ciklusváltozók nem megfelelő viselkedését. Ez a kapcsoló elavult, és lehetséges, hogy a jövőbeli verziókban el lesz távolítva. Javasoljuk, hogy a kód frissítésekor ne használja ezt a kapcsolót. További információ: /Zc:forScope- elavult.

A frissítéskor gyakran előforduló fordítóhiba például az, amikor a rendszer egy nem const argumentumot ad át egy const paraméternek. A fordító régebbi verziói nem mindig jelölték hibaként. További információ: A fordító szigorúbb konverziói.

További információ az egyes megfelelőségi fejlesztésekről: Visual C++ változáselőzmények 2003– 2015 és C++ megfelelőség a Visual Studióban.

Integráltípusokat érintő <stdint.h> hibák

A <stdint.h> fejléc olyan típusdefeket és makrókat határoz meg, amelyek a beépített integráltípusoktól eltérően minden platformon garantáltan meghatározott hosszúságúak lesznek. Néhány példa: uint32_t és int64_t. A <stdint.h> fejléc a Visual Studio 2010-ben lett hozzáadva. Előfordulhat, hogy a 2010 előtt írt kód magándefiníciókat adott meg ezekhez a típusokhoz. És előfordulhat, hogy ezek a definíciók nem mindig összhangban vannak a <stdint.h> definíciókkal.

Ha a hiba C2371, és egy stdint típus szerepel benne, az valószínűleg azt jelenti, hogy a típus egy fejlécben van definiálva a kódban vagy egy külső kódtárfájlban. Frissítéskor meg kell szüntetnie a típusok egyéni definícióit <stdint.h> , de először hasonlítsa össze az egyéni definíciókat a jelenlegi standard definíciókkal, hogy ne okozzon új problémákat.

Az F12 (Ugrás a definícióra) billentyűkombinációval megtekintheti, hogy a szóban forgó típus hol van definiálva.

A /showIncludes fordító itt hasznos lehet. A projekt tulajdonságlapjai párbeszédpanelen válassza a Konfigurációs tulajdonságok>C/C++>Speciális lapot, és állítsa a Belek megjelenítéseigen értékre. Ezután építse újra a projektet. A kimeneti ablakban megjelenik a fájlok listája #include . Minden fejléc be van húzva az azt tartalmazó fejléc alá.

CRT-függvényeket érintő hibák

Az évek során számos módosítás történt a C futtatókörnyezetben. A függvények számos biztonságos verziója lett hozzáadva, és néhányat eltávolítottak. A cikk korábbi részében leírtaknak megfelelően a Microsoft a CRT implementációját a Visual Studio 2015-ben új bináris fájlokká és társított .lib fájlokká alakította át.

Ha egy hiba CRT-függvényt érint, a Visual Studio 2003–2015-ös vagy C++ megfelelőségi fejlesztései között kereshet a Visual C++ változáselőzményeiben, hogy ezek a cikkek tartalmaznak-e további információkat. Ha a hiba LNK2019, győződjön meg arról, hogy a függvény nem lett eltávolítva. Ellenkező esetben, ha biztos benne, hogy a függvény továbbra is létezik, és a hívó kód helyes, ellenőrizze, hogy a projekt használja-e /NODEFAULTLIB. Ha igen, frissítenie kell a kódtárak listáját az új univerzális (UCRT) kódtárak használatához. További információkért lásd a könyvtárról és a függőségről szóló fenti szakaszt.

Ha a hiba magában foglalja printf vagy scanf, győződjön meg arról, hogy egyik függvényt sem definiálja magánjellegűen stdio.h nélkül. Ha igen, távolítsa el a magándefiníciókat, vagy hivatkozzon a legacy_stdio_definitions.lib. Ezt a tárat a Tulajdonságok lapjai párbeszédpanelen, a Konfiguráció tulajdonságai, >> részén, a További függőségek tulajdonságnál állíthatja be. Ha a Windows SDK 8.1 vagy korábbi verziójára hivatkozik, adja hozzá legacy_stdio_definitions.lib.

Ha a hiba sztring argumentumainak formázásával jár, akkor valószínűleg azért van, mert a fordító szigorúbban érvényesíti a szabványt. További információkért tekintse meg a változáselőzményeket. Ügyeljen az esetleges hibákra, mert biztonsági kockázatot jelenthetnek.

A C++ szabvány változásai által okozott hibák

Maga a C++ szabvány olyan módokon fejlődött, amelyek nem mindig kompatibilisek visszamenőlegesen. A C++11 bevezette a mozgás szemantikáját, az új kulcsszavakat, valamint az egyéb nyelvi és standard kódtár-funkciókat. Ezek a módosítások fordítóhibákat és akár eltérő futtatókörnyezeti működést is okozhatnak.

Előfordulhat például, hogy egy régi C++ program tartalmazza a fejlécet iostream.h . Ez a fejléc a C++ előzményeinek korai szakaszában elavult, és végül teljesen el lett távolítva a Visual Studióból. Ebben az esetben használnia kell a <iostream> elemet, és át kell írnia a kódját. További információ: Régi iostream kód frissítése.

C4838: szűkítő konverziós figyelmeztetés

A C++ szabvány most azt határozza meg, hogy az aláíratlanból aláírt integrált értékekké való átalakítások szűkítik a konverziókat. A fordító nem emelte ki ezt a figyelmeztetést a Visual Studio 2015 előtt. Ellenőrizze az egyes előfordulásokat, hogy a szűkítés ne befolyásolja-e a kód helyességét.

Figyelmeztetések a biztonságos CRT-függvények használatára

Az évek során bevezették a C futtatókörnyezeti függvények biztonságos verzióit. Bár a régi, nem biztonságos verziók továbbra is elérhetők, javasoljuk, hogy módosítsa a kódot a biztonságos verziók használatára. A fordító figyelmeztetést küld a nem biztonságos verziók használatára vonatkozóan. Letilthatja vagy figyelmen kívül hagyhatja ezeket a figyelmeztetéseket. Ha le szeretné tiltani a megoldás összes projektjének figyelmeztetését, nyissa meg a View>Property Managert, jelölje ki az összes projektet, amelynek le szeretné tiltani a figyelmeztetést, majd kattintson a jobb gombbal a kijelölt elemekre, és válassza a Tulajdonságok parancsot. A Tulajdonságok lapjai párbeszédpanel Konfigurációs tulajdonságok> alatt, a Speciális> csoportban válassza az Adott figyelmeztetések letiltása lehetőséget. Kattintson a legördülő nyílra, majd a Szerkesztés gombra. Írja be a 4996-ot a szövegmezőbe. (Ne tartalmazza a "C" előtagot.) További információért lásd: Porting to use the Secure CRT.

Windows API-k vagy elavult SDK-k változásai által okozott hibák

Az évek során Windows API-k és adattípusok lettek hozzáadva, és néha módosultak vagy el lettek távolítva. Más SDK-k is, amelyek nem tartoztak a központi operációs rendszerhez, jöttek és mentek. A régebbi programok már nem létező API-k hívásait is tartalmazhatják. Lehet, hogy olyan API-khoz való hívásokat is tartalmaznak, amelyek már nem támogatottak más Microsoft SDK-kban. Láthat hibákat a hiányzó Windows API-kkal vagy a régebbi Microsoft SDK-k API-jaival kapcsolatban. Lehetséges, hogy az API-kat eltávolították vagy felváltották az újabb, biztonságosabb függvények.

A Windows API dokumentációja felsorolja a minimális vagy maximális támogatott operációs rendszereket. Egy adott Windows API-val kapcsolatos információkért tekintse meg az asztali Windows-alkalmazások API-indexében.

Windows-verzió

A Windows API-t közvetlenül vagy közvetve használó programok frissítésekésekor el kell döntenie, hogy melyik windowsos verzió legyen támogatott. A legtöbb esetben a Windows 7 jó választás. További információ: Fejlécfájl-problémák. A WINVER makró meghatározza a Windows legrégebbi verzióját, amelyen a program fut. Ha az MFC-program WINVER értékét 0x0501-re (Windows XP) állítja, figyelmeztetést kap, mert az MFC már nem támogatja az XP-t, akkor sem, ha a build eszközök rendelkeznek XP móddal. A Windows XP buildelési eszközeinek támogatása a Visual Studio 2017-ben véget ért, a Windows 7, a 8.0 és a 8.1 támogatása pedig a Visual Studio 2026-ban fejeződött be.

További információ: A cél windowsos verziójának frissítése és elavultabb fejlécfájlok.

ATL / MFC

Az ATL és az MFC viszonylag stabil API-k, de időnként módosításokat hajtanak végre. További információ: Visual C++ változáselőzmények 2003–2015, A Visual Studio Visual C++ újdonságai és a Visual Studio C++ megfelelőségi fejlesztései.

Az LNK 2005 _DllMain@12 már definiálva van az MSVCRTD.lib fájlban.

Ez a hiba MFC-alkalmazásokban fordulhat elő. Rendezési problémát jelez a CRT-kódtár és az MFC-kódtár között. Az MFC-t először össze kell kapcsolni, hogy biztosítsa a new és delete operátorokat. A hiba kijavításához használja a kapcsolót az /NODEFAULTLIB alapértelmezett kódtárak figyelmen kívül hagyásához: MSVCRTD.lib és mfcs140d.lib. Ezután vegye fel ugyanazokat a kódtárakat, mint a további függőségeket.

32 és 64 bites

Ha az eredeti kód 32 bites rendszerekhez van lefordítva, lehetősége van egy 64 bites verzió létrehozására az új 32 bites alkalmazás helyett (vagy azon kívül). Általában először 32 bites módban kell összeállítania a programot, majd meg kell próbálnia a 64 bites módban. A 64 bites fordítás egyszerű, de bizonyos esetekben felfedheti a 32 bites buildek által elrejtett hibákat.

Ezen túlmenően tisztában kell lennie a fordítási idejű és futásidejű problémákkal, amelyek a mutató méretével, az idő- és méretértékekkel, valamint a méretspecifikus formátumjelölőkkel kapcsolatosak a printf és scanf függvényekben. További információ: A Microsoft C++ konfigurálása 64 bites, x64-alapú célokhoz és a Microsoft C++ 64 bites migrálással kapcsolatos gyakori problémái. További áttelepítési tippekért tekintse meg a 64 bites Windows programozási útmutatóját.

Unicode és MBCS/ASCII

A Unicode szabványosítása előtt számos program a többbájtos karakterkészletet (MBCS) használta az ASCII-karakterkészletben nem szereplő karakterek megjelenítésére. A régebbi MFC-projektekben az MBCS volt az alapértelmezett beállítás. Amikor frissít egy ilyen programot, figyelmeztetések jelennek meg, amelyek a Unicode használatát javasolják. Ha úgy dönt, hogy a Unicode-ra való átalakítás nem éri meg a fejlesztési költséget, letilthatja vagy figyelmen kívül hagyhatja a figyelmeztetést. Ha le szeretné tiltani a megoldás összes projektjéhez, nyissa meg aTulajdonságkezelő>, jelölje ki az összes olyan projektet, amelynek le szeretné tiltani a figyelmeztetést, majd kattintson a jobb gombbal a kijelölt elemekre, és válassza a Tulajdonságok parancsot. A Tulajdonságlapok párbeszédpanelen válassza a Konfigurációs tulajdonságok>> lehetőséget. Az Adott figyelmeztetések letiltása tulajdonságban nyissa meg a legördülő nyilat, majd válassza a Szerkesztés lehetőséget. Írja be a 4996-ot a szövegmezőbe. (Ne tartalmazza a "C" előtagot.) A tulajdonság mentéséhez kattintson az OK gombra, majd az OK gombra a módosítások mentéséhez.

További információ: Portolás MBCS-ről Unicode-ra. Az MBCS-ről és a Unicode-ról általános információkat a Microsoft C++ szövegekről és sztringekről, valamint a Nemzetközivé tétel című témakörökben talál.

Lásd még

Projektek frissítése a Microsoft C++ korábbi verzióiról
C++ megfelelőségi fejlesztések a Visual Studio