Přehled potenciálních problémů s upgradem (Visual C++)

V průběhu let prošel kompilátor C++ mnoho změn spolu se změnami v samotném jazyce C++, standardní knihovně jazyka C++, modulu runtime jazyka C (CRT) a dalších knihoven, jako jsou MFC a ATL. V důsledku toho se při upgradu aplikace ze starší verze sady Visual Studio můžou zobrazit chyby kompilátoru a linkeru a upozornění v kódu, který byl dříve zkompilován čistě. Starší původní základ kódu, tím větší je potenciál takových chyb. Tento přehled shrnuje nejběžnější třídy problémů, které pravděpodobně uvidíte, a obsahuje odkazy na podrobnější informace.

Poznámka

V minulosti jsme doporučili, aby se upgrady, které zahrnují několik verzí sady Visual Studio, prováděly postupně jednu verzi najednou. Tento přístup už nedoporučujeme. Zjistili jsme, že upgrade na nejnovější verzi sady Visual Studio je téměř vždy jednodušší bez ohledu na to, jak staré je základ kódu.

Dotazy nebo komentáře k procesu upgradu lze odeslat na vcupgrade@microsoft.com.

Závislosti sady nástrojů a knihovny

Poznámka

Tato část se týká aplikací a knihoven vytvořených v sadě Visual Studio 2013 a starších verzích. Sady nástrojů používané v sadě Visual Studio 2015, Visual Studio 2017 a Visual Studio 2019 jsou binární kompatibilní. Další informace naleznete v tématu Binární kompatibilita jazyka C++ mezi verzemi sady Visual Studio.

Když upgradujete aplikaci ze sady Visual Studio 2013 nebo dřív na novější verzi, často se doporučuje a je nutné upgradovat všechny knihovny a knihovny DLL, na které aplikace odkazuje. Buď musíte mít přístup ke zdrojovému kódu, nebo dodavatel knihovny musí poskytnout nové binární soubory zkompilované se stejnou hlavní verzí kompilátoru. Pokud je jedna z těchto podmínek pravdivá, můžete tuto část přeskočit, která se zabývá podrobnostmi o binární kompatibilitě. Pokud tomu tak není, nemusí knihovny v upgradované aplikaci fungovat. Informace v této části vám pomůžou pochopit, jestli můžete pokračovat v upgradu.

Sada nástrojů

Formáty .obj souborů .lib jsou dobře definované a zřídka se mění. Někdy se doplňky vytvářejí v těchto formátech souborů, ale tyto doplňky obecně neovlivňují schopnost novějších sad nástrojů využívat soubory objektů a knihovny vytvořené staršími sadami nástrojů. Hlavní výjimkou je, pokud kompilujete pomocí /GL (Kdo le Optimalizace programu). Pokud kompilujete pomocí /GL, můžete výsledný soubor objektu propojit pouze pomocí stejné sady nástrojů, která byla použita k jeho vytvoření. Pokud tedy vytvoříte soubor objektu s kompilátorem /GL sady Visual Studio 2017 (v141), musíte ho propojit pomocí linkeru Visual Studio 2017 (v141). Je to proto, že interní datové struktury v souborech objektů nejsou stabilní pro hlavní verze sady nástrojů. Novější sady nástrojů nerozumí starším formátům dat.

C++ nemá stabilní binární rozhraní aplikace (ABI). Visual Studio ale udržuje stabilní C++ ABI pro všechny podverze vydané verze. Sady nástrojů sady Visual Studio 2015 (v140), Visual Studio 2017 (v141), Visual Studio 2019 (v142) a Visual Studio 2022 (v143) se liší pouze v jejich podverze. Všechny mají stejné číslo hlavní verze, což je 14. Další informace naleznete v tématu Binární kompatibilita jazyka C++ mezi verzemi sady Visual Studio.

Pokud máte soubor objektu s externími symboly s propojením jazyka C++, nemusí se tento soubor objektu správně propojit se soubory objektů vytvořenými jinou hlavní verzí sady nástrojů. Existuje mnoho možných výsledků: propojení může selhat zcela (například pokud se změnila dekorace názvu). Propojení může proběhnout úspěšně, ale aplikace může selhat za běhu (například pokud se změnilo rozložení typu). Nebo vaše aplikace může dál fungovat a nic se nepokazí. Všimněte si také, že i když C++ ABI není stabilní, jsou C ABI a podmnožina C++ ABI vyžadované pro com stabilní.

Pokud propojíte knihovnu importu, může být za běhu použita jakákoli novější verze redistribuovatelných knihoven sady Visual Studio, které zachovávají kompatibilitu ABI. Pokud například zkompilujete a propojíte aplikaci pomocí sady nástrojů Visual Studio 2015 Update 3, můžete později použít distribuovatelné součásti. Je to proto, že knihovny 2015, 2017, 2019 a 2022 zachovaly zpětnou binární kompatibilitu. Opačná hodnota není pravdivá: Pro starší verzi sady nástrojů nemůžete použít redistribuci, než jste použili k sestavení jakékoli součásti kódu.

Knihovny

Pokud máte #include konkrétní verzi souborů hlaviček, musíte výsledný soubor objektu propojit se stejnou verzí knihoven. Pokud například zdrojový soubor obsahuje Visual Studio 2015 Update 3 <immintrin.h>, musíte odkazovat s knihovnou Visual Studio 2015 Update 3 vcruntime . Podobně pokud zdrojový soubor obsahuje Visual Studio 2017 verze 15.5 <iostream>, musíte odkazovat s knihovnou Visual Studio 2017 verze 15.5 Standard C++, msvcprt. Kombinování a párování se nepodporuje.

Pro standardní knihovnu C++ byla kombinace a párování explicitně zakázána použitím #pragma detect_mismatch standardních hlaviček od sady Visual Studio 2010. Pokud se pokusíte propojit nekompatibilní soubory objektů nebo pokud propojíte s nesprávnou standardní knihovnou, odkaz selže.

Starší verze CRT pro kombinování a párování se nikdy nepodporovala, ale často to fungovalo, protože povrch rozhraní API se v průběhu času moc nezměnil. Univerzální CRT přerušila zpětnou kompatibilitu, aby v budoucnu bylo možné zachovat zpětnou kompatibilitu. V budoucnu nemáme v úmyslu zavést nové binární soubory UNIVERSAL CRT s verzemi. Místo toho se stávající univerzální CRT teď aktualizuje na místě.

Abychom zajistili částečnou kompatibilitu propojení se soubory objektů (a knihovnami) zkompilovanými se staršími verzemi hlaviček modulu Microsoft C Runtime, poskytujeme knihovnu , legacy_stdio_definitions.libse sadou Visual Studio 2015 a novějšími. Tato knihovna poskytuje symboly kompatibility pro většinu funkcí a exportů dat, které byly odebrány z univerzálního CRT. Sada symbolů kompatibility, které legacy_stdio_definitions.lib poskytuje, stačí k uspokojení většiny závislostí, včetně všech závislostí v knihovnách zahrnutých v sadě Windows SDK. Některé symboly však byly odebrány z Univerzální CRT, které nemají symboly kompatibility. Tyto symboly zahrnují jak některé funkce (například __iob_func), tak i exporty dat (například __imp___iob, __imp___pctype, __imp___mb_cur_max).

Pokud máte statickou knihovnu vytvořenou pomocí starší verze hlaviček modulu runtime jazyka C, doporučujeme v tomto pořadí následující akce:

1. Znovu sestavte statickou knihovnu pomocí nové verze sady Visual Studio a hlaviček Universal CRT pro podporu propojení s univerzálním CRT. Tento přístup je plně podporovaný a nejlepší možnost.

2. Pokud nemůžete (nebo nechcete) znovu sestavit statickou knihovnu, můžete zkusit vytvořit propojení s legacy_stdio_definitions.lib. Pokud splňuje závislosti na čase propojení vaší statické knihovny, budete chtít statickou knihovnu důkladně otestovat, jak se používá v binárním souboru. Ujistěte se, že to nemá nepříznivý vliv na žádné změny chování, které byly provedeny v Univerzální CRT.

3. Možná, že závislosti statické knihovny nejsou spokojeny legacy_stdio_definitions.lib nebo knihovna nefunguje s univerzálním CRT kvůli změnám chování. V tomto případě doporučujeme zapouzdřit statickou knihovnu do knihovny DLL, kterou propočítáte s požadovanou verzí modulu Microsoft C Runtime. Pokud byla například vytvořená statická knihovna pomocí sady Visual Studio 2013, sestavte tuto knihovnu DLL také pomocí sady nástrojů Sady Visual Studio 2013 a knihoven jazyka C++. Vytvořením knihovny do knihovny DLL zapouzdřete podrobnosti implementace, která je závislá na konkrétní verzi modulu Microsoft C Runtime. Dávejte pozor, aby rozhraní DLL nevracení podrobností o tom, který modul runtime jazyka C používá, například pokud vrací FILE* přes hranici knihovny DLL, nebo malloc-přidělený ukazatel, který volající musí free.

Použití více CRT v jednom procesu není a samo o sobě problematické. (Ve skutečnosti většina procesů načítá několik knihoven DLL CRT. Například součásti operačního systému Windows závisí na msvcrt.dlla CLR závisí na vlastní privátní CRT.) K problémům dochází, když zmálíte stav z různých CRT. Například byste neměli přidělovat paměť pomocí msvcr110.dll!malloc a pokoušet se uvolnit tuto paměť pomocí msvcr120.dll!free, a neměli byste se pokoušet otevřít soubor pomocí msvcr110!fopen a pokus o čtení z daného SOUBORU pomocí msvcr120!fread. Pokud nesměšníte stav z různých CRT, můžete bezpečně mít několik CRT načtených v jednom procesu.

Další informace naleznete v tématu Upgrade kódu na Univerzální CRT.

Chyby způsobené nastavením projektu

Pokud chcete zahájit proces upgradu, otevřete starší projekt, řešení nebo pracovní prostor v nejnovější verzi sady Visual Studio. Visual Studio vytvoří nový projekt na základě původního nastavení projektu. Zkontrolujte, jestli starší projekt obsahuje cesty knihovny nebo obsahují cesty, které jsou pevně zakódované do nestandardních umístění. Je možné, že soubory v těchto cestách nebudou pro kompilátor viditelné, když projekt použije výchozí nastavení. Další informace naleznete v tématu Linker OutputFile nastavení.

Obecně platí, že teď je skvělý čas uspořádat kód projektu, aby se zjednodušila údržba projektu a pomohla vám co nejrychleji sestavit upgradovaný kód. Pokud je zdrojový kód již dobře uspořádaný a váš starší projekt se zkompiluje v sadě Visual Studio 2010 nebo novějším, můžete ručně upravit nový soubor projektu, aby podporoval kompilaci na starém i novém kompilátoru. Následující příklad ukazuje, jak zkompilovat Visual Studio 2015 i Visual Studio 2017:

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

LNK2019: Nevyřešený externí

U nevyřešených symbolů možná budete muset opravit nastavení projektu.

• Pokud je zdrojový soubor v nestandardním umístění, přidali jste cestu k adresářům zahrnutí projektu?

• Pokud je externí definován v .lib souboru, zadali jste cestu lib ve vlastnostech projektu a je tam správná verze .lib souboru?

• Pokoušíte se propojit .lib soubor, který byl zkompilován s jinou verzí sady Visual Studio? Pokud ano, přečtěte si předchozí část o závislostech knihoven a sad nástrojů.

• Odpovídají typy argumentů v lokalitě volání stávající přetížení funkce? Ověřte, že základní typy jsou to, co očekáváte, a to jak pro všechny typy v podpisu funkce, tak i v kódu, který funkci volá.

Při řešení potíží s nevyřešenými chybami symbolů můžete dumpbin.exe prozkoumat symboly definované v binárním souboru. Zkuste zobrazit symboly definované v knihovně pomocí následujícího příkazového řádku:

dumpbin.exe /LINKERMEMBER somelibrary.lib

/Zc:wchar_t (wchar_t Je nativní typ)

(V sadě Microsoft Visual C++ 6.0 a starších wchar_t verzích nebyla implementována jako předdefinovaný typ. Byl deklarován wchar.h jako typedef pro unsigned short.) Standard C++ vyžaduje, aby wchar_t byl integrovaný typ. Použití verze typedef může způsobit problémy s přenositelností. Pokud upgradujete ze starších verzí sady Visual Studio a zobrazí se chyba kompilátoru C2664, protože se kód pokouší implicitně převést wchar_t na unsigned short, doporučujeme změnit kód, abyste chybu opravili místo nastavení /Zc:wchar_t-. Další informace najdete v tématu /Zc:wchar_t (wchar_t Je nativní typ).

Upgrade pomocí možností /NODEFAULTLIBlinkeru , /ENTRYa /NOENTRY

Možnost linkeru /NODEFAULTLIB(nebo vlastnost Ignorovat všechny výchozí knihovny ) říká linkeru, že se má automaticky propojit ve výchozích knihovnách, jako je CRT. To znamená, že každá knihovna musí být uvedena jako vstup jednotlivě. Tento seznam knihoven je uveden ve vlastnosti Další závislosti v části Linker dialogového okna Vlastnosti projektu.

Projekty, které používají tuto možnost, představují problém při upgradu, protože obsah některých výchozích knihoven byl refaktorován. Vzhledem k tomu, že každá knihovna musí být uvedena ve vlastnosti Další závislosti nebo na příkazovém řádku linkeru, musíte aktualizovat seznam knihoven tak, aby používaly všechny aktuální názvy.

Následující tabulka ukazuje knihovny, jejichž obsah se změnil od sady Visual Studio 2015. Pokud chcete upgradovat, musíte do knihoven v prvním sloupci přidat nové názvy knihoven ve druhém sloupci. Některé z těchto knihoven jsou knihovny importu, ale to by nemělo být důležité.

Pokud jste používali:	Potřebujete použít tyto knihovny:
libcmt.lib	libcmt.lib, libucrt.lib, libvcruntime.lib
libcmtd.lib	libcmtd.lib, libucrtd.lib, libvcruntimed.lib
msvcrt.lib	msvcrt.lib, ucrt.lib, vcruntime.lib
msvcrtd.lib	msvcrtd.lib, ucrtd.lib, vcruntimed.lib

Stejný problém platí i v případě, že použijete /ENTRY možnost nebo /NOENTRY možnost, která má také vliv na obejití výchozích knihoven.

Chyby způsobené vylepšeným dodržováním jazyka

Kompilátor Jazyka Microsoft C++ v průběhu let neustále vylepšuje shodu se standardem C++. Kód, který je zkompilován v dřívějších verzích, se nemusí podařit zkompilovat v novějších verzích sady Visual Studio. Důvodem je to, že kompilátor správně označí chybu, kterou dříve ignorovala nebo explicitně povolila.

Přepínač byl například /Zc:forScope zaveden v rané fázi historie MSVC. Umožňuje nekonformní chování proměnných smyčky. Tento přepínač je teď zastaralý a může být odebrán v budoucích verzích. Důrazně doporučujeme tento přepínač při upgradu kódu nepoužívat. Další informace najdete v tématu /Zc:forScope- o zastaralém stavu.

Jedním z příkladů běžné chyby kompilátoru, která se může zobrazit při upgradu, je, když je argument const předán parametru const. Starší verze kompilátoru ji vždy neoznačily jako chybu. Další informace naleznete v tématu Přísnější převody kompilátoru.

Další informace o konkrétních vylepšeních shody najdete v tématu Historie změn visual C++ 2003 – 2015 a vylepšení shody jazyka C++ v sadě Visual Studio.

Chyby související s <stdint.h> integrálními typy

Hlavička <stdint.h> definuje typedefs a makra, která mají na rozdíl od předdefinovaných integrálních typů zaručenou zadanou délku na všech platformách. Některé příklady jsou uint32_t a int64_t. Záhlaví <stdint.h> bylo přidáno v sadě Visual Studio 2010. Kód, který byl napsán před 2010, mohl poskytnout soukromé definice pro tyto typy. A tyto definice nemusí být vždy konzistentní s <stdint.h> definicemi.

Pokud je chyba C2371 a stdint typ se týká, pravděpodobně to znamená, že typ je definován v hlavičce buď v kódu, nebo v souboru knihovny třetí strany. Při upgradu byste měli eliminovat všechny vlastní definice <stdint.h> typů, ale nejprve porovnejte vlastní definice s aktuálními standardními definicemi, abyste zajistili, že nezadáte nové problémy.

Stisknutím klávesy F12 (Přejít k definici) můžete zjistit, kde je definovaný typ otázky.

Možnost kompilátoru /showIncludes může být užitečná tady. V dialogovém okně Stránky vlastností projektu vyberte stránku Vlastnosti>konfigurace C/C++>Advanced a nastavte Zobrazit zahrnutí na ano. Pak projekt znovu sestavte. V okně výstupu se zobrazí seznam #include souborů. Každé záhlaví je odsazené pod záhlavím, které ho obsahuje.

Chyby související s funkcemi CRT

V průběhu let došlo k mnoha změnám modulu runtime jazyka C. Bylo přidáno mnoho zabezpečených verzí funkcí a některé byly odebrány. Jak je popsáno výše v tomto článku, implementace CRT společnosti Microsoft byla refaktorována v sadě Visual Studio 2015 do nových binárních souborů a přidružených .lib souborů.

Pokud chyba zahrnuje funkci CRT, vyhledejte v sadě Visual Studio vylepšení shody visual C++ 2003 – 2015 nebo C++, abyste zjistili, jestli tyto články obsahují nějaké další informace. Pokud je chyba LNK2019, ujistěte se, že funkce nebyla odebrána. Pokud jste si jisti, že funkce stále existuje a volající kód je správný, zkontrolujte, jestli váš projekt používá /NODEFAULTLIB. Pokud ano, musíte aktualizovat seznam knihoven tak, aby používaly nové univerzální knihovny (UCRT). Další informace najdete v části věnované knihovně a závislostem výše.

Pokud chyba zahrnuje printf nebo scanf, ujistěte se, že soukromě nedefinujete ani jednu funkci bez zahrnutí stdio.h. Pokud ano, buď odeberte soukromé definice nebo propojení s legacy_stdio_definitions.lib. Tuto knihovnu můžete nastavit v dialogovém okně Stránky vlastností v části Vstup linkeru> vlastností>konfigurace ve vlastnosti Další závislosti. Pokud propočítáte se sadou Windows SDK 8.1 nebo staršími verzemi, přidejte legacy_stdio_definitions.lib.

Pokud chyba zahrnuje argumenty řetězce formátu, je pravděpodobné, že kompilátor je přísnější ohledně vynucování standardu. Další informace najdete v historii změn. Věnujte zde velkou pozornost všem chybám, protože můžou potenciálně představovat bezpečnostní riziko.

Chyby způsobené změnami ve standardu C++

Samotný standard C++ se vyvinul způsoby, které nejsou vždy zpětně kompatibilní. C++11 zavedl sémantiku přesunutí, nová klíčová slova a další funkce jazyka a standardní knihovny. Tyto změny mohou potenciálně způsobit chyby kompilátoru a dokonce i jiné chování modulu runtime.

Například starý program C++ může obsahovat hlavičku iostream.h . Tato hlavička byla v rané fázi historie jazyka C++ zastaralá a nakonec se úplně odebrala ze sady Visual Studio. V takovém případě musíte kód použít <iostream> a přepsat. Další informace naleznete v tématu Aktualizace starého iostream kódu.

C4838: Upřesňující upozornění na převod

Standard C++ nyní určuje, že převody z nepodepsaného na znaménka integrální hodnoty jsou zúžení převodů. Kompilátor toto upozornění nevytvořil před sadou Visual Studio 2015. Zkontrolujte každý výskyt a ujistěte se, že zúžení nemá vliv na správnost kódu.

Upozornění na používání zabezpečených funkcí CRT

V průběhu let byly zavedeny zabezpečené verze funkcí modulu runtime jazyka C. I když staré, nezabezpečované verze jsou stále dostupné, doporučujeme změnit kód tak, aby používal zabezpečené verze. Kompilátor vydá upozornění na použití nezabezpečených verzí. Tato upozornění můžete zakázat nebo ignorovat. Chcete-li zakázat upozornění pro všechny projekty ve vašem řešení, otevřete Správce vlastností zobrazení>, vyberte všechny projekty, pro které chcete upozornění zakázat, pak klikněte pravým tlačítkem myši na vybrané položky a zvolte Vlastnosti. V dialogovém okně Stránky vlastností v části Vlastnosti>konfigurace C/C++>Upřesnit vyberte Zakázat konkrétní upozornění. Zvolte šipku rozevíracího seznamu a pak zvolte Upravit. Do textového pole zadejte 4996. (Nezahrnujte předponu jazyka C.) Další informace naleznete v tématu Portování pro použití secure CRT.

Chyby způsobené změnami v rozhraních API systému Windows nebo zastaralých sadÁCH SDK

V průběhu let byla přidána rozhraní API systému Windows a datové typy a někdy se změnily nebo odebraly. Také další sady SDK, které nepatří do základního operačního systému, přišly a zmizely. Starší programy můžou obsahovat volání rozhraní API, která již neexistují. Můžou také obsahovat volání rozhraní API v jiných sadách MICROSOFT SDK, které se už nepodporují. Ve starších sadách Microsoft SDK se můžou zobrazit chyby týkající se chybějících rozhraní API systému Windows nebo rozhraní API. Je možné, že rozhraní API byla odebrána nebo nahrazena novějšími, bezpečnějšími funkcemi.

Dokumentace k rozhraní WINDOWS API uvádí minimální nebo maximální podporované operační systémy. Informace o konkrétním rozhraní API systému Windows najdete v indexu rozhraní API pro desktopové aplikace systému Windows.

Verze Windows

Při upgradu programu, který používá rozhraní API systému Windows přímo nebo nepřímo, musíte rozhodnout o minimální verzi Systému Windows, která se má podporovat. Ve většině případů je systém Windows 7 dobrou volbou. Další informace najdete v tématu Problémy se souborem hlaviček. Makro WINVER definuje nejstarší verzi Windows, na které má program běžet. Pokud je program MFC nastaven WINVER na 0x0501 (Windows XP), zobrazí se upozornění, protože mfc již nepodporuje XP, i když samotná sada nástrojů kompilátoru má režim XP. Podpora sady nástrojů kompilátoru pro Systém Windows XP skončila v sadě Visual Studio 2017.

Další informace naleznete v tématu Aktualizace cílové verze systému Windows a zastaralé hlavičkové soubory.

ATL / MFC

ATL a MFC jsou relativně stabilní rozhraní API, ale občas se provádějí změny. Další informace najdete v tématu Historie změn visual C++ 2003 – 2015, Co je nového pro Visual C++ v sadě Visual Studio a vylepšení shody jazyka C++ v sadě Visual Studio.

LNK 2005 _DllMain@12 již definován v MSVCRTD.lib

K této chybě může dojít v aplikacích MFC. Označuje problém řazení mezi knihovnou CRT a knihovnou MFC. Mfc musí být nejprve propojen, aby poskytoval new a delete operátory. Chcete-li chybu opravit, použijte /NODEFAULTLIB přepínač ignorovat tyto výchozí knihovny: MSVCRTD.lib a mfcs140d.lib. Pak přidejte tyto stejné knihovny jako další závislosti.

32 vs. 64 bitů

Pokud je původní kód zkompilován pro 32bitové systémy, můžete místo (nebo kromě) nové 32bitové aplikace vytvořit 64bitovou verzi. Obecně platí, že program byste měli nejprve kompilovat v 32bitovém režimu a pak se pokusit o 64bitovou verzi. Kompilace pro 64bitovou verzi je jednoduchá, ale v některých případech může odhalit chyby, které byly skryty 32bitovými buildy.

Měli byste také vědět o možných problémech s časem kompilace a modulem runtime souvisejícími s velikostí ukazatele, hodnotami času a velikostí a specifikátory printf formátu specifické pro velikost a scanf funkce. Další informace najdete v tématu Konfigurace jazyka Visual C++ pro 64bitové cíle x64 a běžné problémy s 64bitovou migrací jazyka Visual C++. Další tipy pro migraci najdete v průvodci programováním pro 64bitovou verzi Windows.

Unicode vs MBCS/ASCII

Před standardizovaným kódováním Unicode používalo mnoho programů vícebajtovou znakovou sadu (MBCS) k reprezentaci znaků, které nebyly zahrnuty do znakové sady ASCII. Ve starších projektech MFC byla výchozí nastavení MBCS. Při upgradu takového programu se zobrazí upozornění, která radí místo toho používat Unicode. Pokud se rozhodnete, že převod na Unicode nestojí za náklady na vývoj, můžete upozornění zakázat nebo ignorovat. Pokud ho chcete zakázat pro všechny projekty v řešení, otevřete Správce vlastností zobrazení>, vyberte všechny projekty, pro které chcete upozornění zakázat, a potom klikněte pravým tlačítkem myši na vybrané položky a zvolte Vlastnosti. V dialogovém okně Stránky vlastností vyberte Vlastnosti>konfigurace C/C++>Advanced. Ve vlastnosti Zakázat konkrétní upozornění otevřete šipku rozevíracího seznamu a pak zvolte Upravit. Do textového pole zadejte 4996. (Nezahrnujte předponu jazyka C.) Pokud chcete uložit vlastnost, zvolte OK a uložte provedené změny kliknutím na OK .

Další informace naleznete v tématu Přenos z MBCS do Unicode. Obecné informace o mbCS vs. Unicode naleznete v tématu Text a řetězce v jazyce Visual C++ a Internationalization .

Viz také

Upgrade projektů ze starších verzí jazyka Visual C++
Vylepšení shody C++ se sadou Visual Studio