次の方法で共有

アップグレード時の潜在的な問題の概要 (Visual C++)

  • [アーティクル]

長年にわたり、Microsoft C++ コンパイラでは、C++ 言語自体、C++ 標準ライブラリ、C ランタイム (CRT)、その他のライブラリ (MFC や ATL など) における変更と併せて、多くの変更が行われてきました。 その結果、以前のバージョンの Visual Studio からアプリケーションをアップグレードしたときに、以前は正常にコンパイルされていたコードで、コンパイラ エラー、リンカー エラー、警告が発生する可能性があります。 元のコード ベースが古いほど、このようなエラーが発生する可能性は高くなります。 この概要では、発生する可能性が高い最も一般的な種類の問題について概説し、詳細情報へのリンクを示します。

Note

これまで、Visual Studio の複数のバージョンにまたがるアップグレードは、1 バージョンずつ段階的に実行することをお勧めしていました。 しかし、現在、この方法はお勧めしていません。 コード ベースの古さに関係なく、ほとんどの場合、最新バージョンの Visual Studio にアップグレードする方が簡単であることがわかりました。

アップグレード プロセスに関する質問またはコメントについては、vcupgrade@microsoft.com にお送りください。

ライブラリとツールセットの依存関係

Note

このセクションは、Visual Studio 2013 以前を使ってビルドされたアプリケーションとライブラリに適用されます。 Visual Studio 2015、Visual Studio 2017、Visual Studio 2019 で使用されるツールセットには、バイナリ互換性があります。 詳細については、「Visual Studio のバージョン間の C++ バイナリ互換性」を参照してください。

Visual Studio 2013 以前から新しいバージョンにアプリをアップグレードするときには、多くの場合、アプリのリンク先のすべてのライブラリと DLL をアップグレードすることが推奨されたり、必要であったりします。 ソース コードにアクセスできる必要があるか、ライブラリ ベンダーから同じメジャー バージョンのコンパイラでコンパイルされた新しいバイナリ ファイルが提供されている必要があります。 この条件のいずれかを満たしている場合、バイナリの互換性について説明するこのセクションをスキップすることができます。 どちらも該当しない場合は、アップグレードしたアプリでライブラリが機能しない可能性があります。 このセクションの情報は、アップグレードを続行できるかどうかを理解するのに役立ちます。

ツールセット

.obj および .lib ファイル形式は適切に定義されており、変わることはほとんどありません。 時々これらのファイル形式には追加が行われる場合がありますが、この追加は一般には、より新しいツールセットが以前のツールセットによって生成されたオブジェクト ファイルやライブラリを利用する機能に影響はありません。 重要な例外として、/GL (プログラム全体の最適化) を使用してコンパイルする場合が挙げられます。 /GL を使用してコンパイルした場合、生成されたオブジェクト ファイルをリンクするには、その生成に使用されたものと同じツールセットを使用する必要があります。 そのため、/GL を使用してオブジェクト ファイルを生成し、Visual Studio 2017 (v141) コンパイラを使用する場合は、Visual Studio 2017 (v141) リンカーを使用してリンクする必要があります。 これは、オブジェクト ファイルの内部データ構造がツールセットのメジャー バージョン間で安定しないためです。 新しいツールセットでは、古いデータ形式は認識されません。

C++ のアプリケーション バイナリ インターフェイス (ABI) は安定性がありません。 しかし、Visual Studio では、リリースのすべてのマイナー バージョンについては安定した C++ ABI を維持しています。 Visual Studio 2015 (v140)、Visual Studio 2017 (v141)、Visual Studio 2019 (v142)、Visual Studio 2022 (v143) のツールセットは、マイナー バージョンのみが異なります。 これらはすべて、同じメジャー バージョン 14 です。 詳細については、「Visual Studio のバージョン間の C++ バイナリ互換性」を参照してください。

C++ リンケージを使用した外部シンボルがオブジェクト ファイルに含まれている場合、そのオブジェクト ファイルは、ツールセットの異なるメジャー バージョンで生成されたオブジェクト ファイルと正しくリンクできないことがあります。 さまざまな結果が考えられます。リンクが完全に失敗する場合があります (名前の装飾が変更された場合など)。 リンクは成功しても、アプリが実行時に失敗する可能性があります (型のレイアウトが変更された場合など)。 あるいは、アプリが引き続き動作し、何も問題が発生しないこともあります。 また、C++ ABI は安定していませんが、C ABI および COM に必須の C++ ABI のサブセットは安定していることに注意してください。

インポート ライブラリにリンクすると、ABI との互換性を保持する、Visual Studio の再頒布可能ライブラリの新しいバージョンを実行時に使用することができます。 たとえば、Visual Studio 2015 Update 3 ツールセットを使用してアプリをコンパイルし、リンクした場合、新しい再頒布可能ライブラリを使用できます。 これは、2015、2017、2019、2022 のライブラリでは、バイナリの下位互換性が維持されているためです。 その逆は当てはまりません。コードのコンポーネントのビルドに使用したものよりも前のバージョンのツールセットに再頒布可能ライブラリを使用することはできません。

ライブラリ

特定のバージョンのヘッダー ファイルを #include した場合、生成されたオブジェクト ファイルを同じバージョンのライブラリにリンクする必要があります。 たとえば、Visual Studio 2015 Update 3 の <immintrin.h> がソース ファイルに含まれている場合は、Visual Studio 2015 Update 3 の vcruntime ライブラリとリンクする必要があります。 同様に、Visual Studio 2017 バージョン 15.5 の <iostream> がソース ファイルに含まれている場合は、Visual Studio 2017 バージョン 15.5 の標準 C++ ライブラリである msvcprt とリンクする必要があります。 バージョンの組み合わせはサポートされていません。

C++ 標準ライブラリの場合、Visual Studio 2010 以降、標準ヘッダーに #pragma detect_mismatch を使用することで、バージョンの組み合わせは明示的に禁止されています。 互換性のないオブジェクト ファイルをリンクしようとした場合や、誤った標準ライブラリとリンクした場合、リンクは失敗します。

古い CRT バージョンの組み合わせはサポートされていませんでしたが、長い間、API サーフェイスにあまり変更がなかったため、多くの場合、機能していました。 Universal CRT では下位互換性の問題が解決され、将来的に下位互換性を維持できるようになりました。 今後、バージョン管理された新しい Universal CRT バイナリを導入する予定はありません。 その代わり、既存の Universal CRT を適切に更新できるようになりました。

古いバージョンの Microsoft C ランタイム ヘッダーでコンパイルされたオブジェクト ファイル (およびライブラリ) との部分的なリンク互換性を提供するために、Visual Studio 2015 以降では、legacy_stdio_definitions.lib ライブラリが用意されています。 このライブラリは、Universal CRT から削除された関数とデータ エクスポートの大部分に対して互換性シンボルを提供します。 legacy_stdio_definitions.lib によって提供される互換性シンボルのセットは、Windows SDK に含まれるライブラリ内のすべての依存関係を含め、ほとんどの依存関係を十分に満たしています。 ただし、互換性シンボルがない一部のシンボルは Universal CRT から削除されました。 これらのシンボルには、一部の関数 (例: __iob_func) と一部のデータ エクスポート (例: __imp___iob、__imp___pctype、__imp___mb_cur_max) の両方が含まれます。

古いバージョンの C ランタイム ヘッダーを使用してビルドされたスタティック ライブラリがある場合は、次の操作をこの順番で実行することをお勧めします。

  1. 新しいバージョンの Visual Studio および Universal CRT のヘッダーを使用してスタティック ライブラリをリビルドして、Universal CRT とのリンクをサポートします。 このアプローチは完全にサポートされており、最良の方法です。

  2. スタティック ライブラリをリビルドできない (またはしたくない) 場合は、legacy_stdio_definitions.lib とのリンクを試すことができます。 それがスタティック ライブラリのリンク時の依存関係を満たしている場合は、バイナリで使用されるスタティック ライブラリを十分にテストする必要があります。 Universal CRT に加えられた動作の変更による悪影響を受けていないことを確認します。

  3. スタティック ライブラリの依存関係が legacy_stdio_definitions.lib では満たされないか、動作の変更によってライブラリが Universal CRT で機能しないことが考えられます。 この場合、必要なバージョンの Microsoft C ランタイムとリンクした DLL にスタティック ライブラリをカプセル化することをお勧めします。 たとえば、Visual Studio 2013 を使用してスタティック ライブラリがビルドされている場合は、この DLL も Visual Studio 2013 ツールセットと C++ ライブラリを使用してビルドします。 DLL を生成してライブラリに取り込むことにより、特定のバージョンの Microsoft C ランタイムに対する依存関係を示す実装の詳細をカプセル化します DLL インターフェイスが、たとえば、DLL 境界を超えて FILE* を返す場合や、呼び出し元が free する必要がある、malloc で割り当てられたポインターを返す場合は、インターフェイスが使用している C ランタイムの詳細が漏れないように注意してください。

1 つのプロセスで複数の CRT を使用すること自体に問題はありません (実際に、ほとんどのプロセスは複数の CRT DLL を読み込みます。たとえば、Windows オペレーティング システム コンポーネントは msvcrt.dll に依存し、CLR は独自のプライベート CRT に依存します)。さまざまな CRT からの状態を混ぜると、問題が発生します。 たとえば、msvcr110.dll!malloc を使用してメモリを割り当て、msvcr120.dll!free を使用してそのメモリの割り当て解除を試みたり、msvcr110!fopen を使用して FILE を開き、msvcr120!fread を使用してその FILE からの読み取りを試みたりしないでください。 さまざまな CRT からの状態を混ぜ合わせない限り、1 つのプロセスで複数の CRT を安全に読み込むことができます。

詳細については、「Upgrade your code to the Universal CRT」 (コードを Universal CRT にアップグレードする) を参照してください。

プロジェクト設定に起因するエラー

アップグレード プロセスを開始するには、Visual Studio の最新バージョンで以前のプロジェクト/ソリューション/ワークスペースを開きます。 Visual Studio は、以前のプロジェクトの設定に基づいて新しいプロジェクトを作成します。 古いプロジェクトにライブラリ パスが含まれているか、または標準以外の場所にハードコーディングされたパスが含まれているかを確認します。 プロジェクトで既定の設定が使用されている場合、それらのパス内のファイルがコンパイラに表示されない可能性があります。 詳細については、「Linker OutputFile setting」 (リンカーの OutputFile の設定) を参照してください。

一般に、プロジェクト コードを整理してプロジェクトのメンテナンスを簡素化し、アップグレードされたコードをできるだけすばやくビルドできるようにするには今が絶好の機会です。 ソース コードが既に適切に整理されていて、古いプロジェクトが Visual Studio 2010 以降でコンパイルされている場合は、新旧両方のコンパイラでのコンパイルをサポートするように新しいプロジェクト ファイルを手動で編集できます。 次の例では、Visual Studio 2015 および Visual Studio 2017 の場合のコンパイル方法を示します。

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

LNK2019: 未解決の外部シンボル

未解決のシンボルの場合、プロジェクト設定の修正が必要なことがあります。

  • ソース ファイルが既定以外の場所にある場合、プロジェクトのインクルード ディレクトリのパスを追加しましたか?

  • 外部シンボルが .lib ファイルに定義されている場合、プロジェクト プロパティで lib パスを指定していますか? また、そこには .lib ファイルの正しいバージョンが置かれていますか?

  • 異なるバージョンの Visual Studio でコンパイルされた .lib ファイルへのリンクを試みていますか? 試みている場合は、ライブラリとツールセットの依存関係に関する前のセクションを参照してください。

  • 呼び出しサイトにおける引数の型は、関数の既存のオーバー ロードと実際に一致していますか? 関数のシグネチャ内と関数を呼び出すコード内の typedef の基になる型が想定どおりであることを確認します。

未解決シンボル エラーのトラブルシューティングを行うには、dumpbin.exe を使用して、バイナリで定義されているシンボルを調べます。 次のコマンド ラインを試行して、ライブラリで定義されているシンボルを表示してください。

dumpbin.exe /LINKERMEMBER somelibrary.lib

/Zc:wchar_t (wchar_t をネイティブ型として認識)

(Visual C++ 6.0 以前では、wchar_t は組み込み型として実装されていませんでした。これは、unsigned short の typedef として wchar.h で宣言されていました)。C++ 標準では、wchar_t は組み込み型である必要があります。 typedef バージョンを使用すると、移植性の問題が発生することがあります。 以前のバージョンの Visual Studio からアップグレードするときに、コードが wchar_t を unsigned short に暗黙的に変換しようとしたために C2664 コンパイル エラーが発生した場合は、/Zc:wchar_t- を設定するのではなく、コードを変更してエラーを修正することをお勧めします。 詳細については、「/Zc:wchar_t (wchar_t をネイティブ型として認識)」を参照してください。

リンカー オプション /NODEFAULTLIB、/ENTRY、/NOENTRY を使用したアップグレード

/NODEFAULTLIB リンカー オプション (または [すべての既定のライブラリの無視] リンカー プロパティ) は、CRT などの既定のライブラリ内で自動的にリンクしないようにリンカーに指示します。 これは、各ライブラリが、入力として個別にリストされる必要があることを意味します。 このライブラリ リストは、[プロジェクトのプロパティ] ダイアログの [リンカー] セクションにある [追加の依存関係] プロパティに指定されます。

このオプションを使用しているプロジェクトでは、アップグレード時に問題が発生します。これは、既定のいくつかのライブラリでコンテンツのリファクタリングが行われていることが原因です。 各ライブラリは [追加の依存関係] プロパティ内またはリンカーのコマンドラインに一覧表示される必要があるため、すべての現在の名前が使用されるようにライブラリのリストを更新する必要があります。

次の表に、Visual Studio 2015 以降、コンテンツが変更されたライブラリを示します。 アップグレードするには、2 番目の列内の新しいライブラリの名前を、1 番目の列内のライブライに追加する必要があります。 これらのライブラリの一部はインポート ライブラリですが、そのことは重要ではありません。

次を使用していた場合 次のライブラリを使用する必要があります
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

また、/ENTRY オプションあるいは /NOENTRY オプションを使用する場合 (これらには既定のライブラリをバイパスする効果もある)、同じ問題が発生します。

言語の適合性の強化に起因するエラー

Microsoft C++ コンパイラは、長年にわたり、C++ 標準への適合性を強化し続けててきました。 以前のバージョンでコンパイルされたコードは、新しいバージョンの Visual Studio でコンパイルできない場合があります。 これは、コンパイラによって、以前は無視されていたか、明示的に許可されていたエラーに適切にフラグが設定されるようになったためです。

たとえば、/Zc:forScope スイッチは、MSVC の歴史の早い段階で導入されました。 このスイッチでは、ループ変数に対する非準拠の動作が許可されます。 このスイッチは非推奨となりました。将来のバージョンでは削除される可能性があります。 コードをアップグレードするときは、このスイッチを使用しないことを強くお勧めします。 詳細については、非推奨になった /Zc:forScope- に関するセクションを参照してください。

アップグレード時によく発生するコンパイラ エラーの例として、非 const 引数が const パラメーターに渡された場合に発生するエラーが挙げられます。 古いバージョンのコンパイラでは、これに対して常にエラーのフラグが設定されるとは限りませんでした。 詳細については、「コンパイラのより厳密な変換」を参照してください。

特定の適合性強化の詳細については、Visual C++ change history 2003 - 2015 (Visual C++ 2003 から 2015 での互換性に影響する変更点) および「C++ conformance improvements in Visual Studio」 (Visual Studio での C++ 適合性強化) を参照してください。

<stdint.h> 整数型に関係するエラー

<stdint.h> ヘッダーでは、組み込みの整数型とは異なり、すべてのプラットフォームで指定された長さを保持することが保証される typedef と macro を定義します。 uint32_t と int64_t は、その例です。 <stdint.h> ヘッダーは、Visual Studio 2010 で追加されました。 2010 より前に記述されたコードでは、型のプライベート定義が指定されている場合があります。 また、それらの定義は、<stdint.h> の定義と必ずしも一致しているとは限りません。

エラーが C2371 であり、stdint 型が関係している場合、その多くは、コード内またはサードパーティのライブラリ ファイル内のヘッダーでこの型が定義されていることを意味しています。 アップグレード時に、<stdint.h> 型のカスタム定義を削除する必要がありますが、最初に、カスタム定義を現在の標準定義と比較して、新たな問題が発生しないことを確認してください。

F12 キー (定義へ移動) を押すと、問題の型が定義されている場所を確認できます。

ここでは、/showIncludes コンパイラ オプションが役立ちます。 プロジェクトの [プロパティ ページ] ダイアログ ボックスで、[構成プロパティ]>[C/C++]>[詳細設定] ページの順に選択し、[インクルード ファイルの表示] を [はい] に設定します。 その後、プロジェクトをリビルドします。 出力ウィンドウに #include ファイルのリストが表示されます。 各ヘッダーは、それぞれが含まれているヘッダーの下にインデントされます。

CRT の関数に関係するエラー

C ランタイムには、長年にわたり、多くの変更が加えられてきました。 セキュリティで保護された関数のバージョンが多数追加された一方で、削除された関数もありました。 また、この記事で前述したように、Microsoft の CRT 実装は、Visual Studio 2015 で新しいバイナリと関連する .lib ファイルにリファクタリングされました。

エラーが CRT 関数に関係している場合は、記事に追加情報が含まれるかどうか、「Visual C++ 2003 から 2015 の変更履歴」または Visual Studio での C++ 準拠の改善に関するページを検索してください。 エラーが LNK2019 の場合は、関数が削除されていないことを確認します。 関数がまだ存在し、呼び出し元のコードが正しい場合は、プロジェクトで /NODEFAULTLIB が使用されているかどうかを確認します。 使用されている場合は、新しいユニバーサル (UCRT) ライブラリを使用するように、ライブラリのリストを更新する必要があります。 詳細については、ライブラリと依存関係に関する上記セクションを参照してください。

エラーが printf または scanf に関係している場合は、どちらの関数も stdio.h を含めずにプライベートに定義されていないことを確認します。 定義されている場合は、プライベート定義または legacy_stdio_definitions.lib へのリンクを削除します。 [プロパティ ページ] ダイアログの [追加の依存関係] プロパティで [構成プロパティ]>[リンカー]>[入力] の順に選択して、このライブラリを設定することができます。 Windows SDK 8.1 以前とリンクする場合は、legacy_stdio_definitions.lib を追加します。

エラーが書式文字列の引数に関係している場合は、おそらく、コンパイラが標準の適用により厳格であることが原因です。 詳細については、変更履歴を参照してください。 ここでのエラーは、セキュリティ上のリスクを招く可能性があるので、十分に注意してください。

C++ 標準の変更に起因するエラー

C++ 標準自体、進化の過程で常に下位互換性が保たれていたわけではありませんでした。 C++11 では、移動セマンティクス、新しいキーワード、言語および標準ライブラリの他の機能が導入されました。 これらの変更により、コンパイラ エラーが発生したり、実行時の動作が異なったりする可能性があります。

たとえば、古い C++ プログラムには、iostream.h ヘッダーが含まれている場合があります。 このヘッダーは、C++ の歴史の早い段階で非推奨となり、最終的には Visual Studio から完全に削除されました。 この場合、<iostream> を使用してコードを書き換える必要があります。 詳細については、古い iostream コードの更新に関するセクションを参照してください。

C4838: 縮小変換に関する警告

C++ 標準では、符号なし整数値から符号付き整数値への変換は縮小変換であることが示されるようになりました。 Visual Studio 2015 より前のコンパイラでは、この警告は発生しませんでした。 発生した各警告を調べて、縮小変換がコードの正確性に影響しないことを確認します。

セキュリティで保護された CRT 関数を使用するように助言する警告

時間をかけて、C ランタイム関数のセキュリティで保護されたバージョンが導入されてきました。 セキュリティ保護されていない古いバージョンは引き続き使用できますが、セキュリティで保護されたバージョンを使用するようにコードを変更することをお勧めします。 セキュリティで保護されていないバージョンが使用されている場合は、コンパイラが警告を発行するようになります。 これらの警告は、無効にすることも無視することもできます。 ソリューション内のすべてのプロジェクトに対して警告を無効にするには、[表示]>[プロパティ マネージャー] の順に開き、警告を無効にするすべてのプロジェクトを選択し、選択した項目を右クリックして、[プロパティ] を選択します。 [プロパティ ページ] ダイアログで [構成プロパティ]>[C/C++]>[詳細] の順に選択し、[指定の警告を無効にする] を選択します。 ドロップダウン矢印を選択し、[編集] を選択します。 テキスト ボックスに「4996」と入力します (プレフィックス "C" を含めないでください)。詳細については、「Secure CRT を使用するよう移植する」を参照してください。

Windows API または古い SDK での変更に起因するエラー

長年にわたり、Windows API とデータ型が追加されてきました。これらは変更されたり削除されたりすることもありました。 また、コア オペレーティング システムに属していない SDK の中には、登場しては消えていったものもあります。 古いプログラムには、既に存在しない API の呼び出しが含まれている場合があります。 サポートされなくなった他の Microsoft SDK の API の呼び出しが含まれている場合もあります。 Windows API または古い Microsoft SDK の API が見つからないことに関するエラーが表示される場合があります。 API が削除されたか、セキュリティが強化された新しい関数に置き換えられた可能性があります。

Windows API ドキュメントには、サポートされるオペレーティング システムの最小バージョンと最大バージョンが記載されています。 特定の Windows API については、「Windows デスクトップ アプリケーションの API インデックス」を参照してください。

Windows バージョン

Windows API を直接または間接的に使用するプログラムをアップグレードする場合は、サポートする Windows の最小バージョンを決定する必要があります。 ほとんどの場合は、Windows 7 が適切な選択となります。 詳細については、ヘッダー ファイルの問題に関するページを参照してください。 WINVER マクロでは、プログラムを実行できる最も古い Windows バージョンが定義されます。 MFC プログラムで WINVER が 0x0501 (Windows XP) に設定されている場合、警告が表示されます。これは、コンパイラ ツールセット自体に XP モードがあっても、MFC で XP がサポートされなくなったためです。 Windows XP のコンパイラ ツールセットのサポートは、Visual Studio 2017 で終了しました。

詳細については、ターゲットの Windows バージョンの更新に関するセクションおよびその他の期限切れのヘッダー ファイルに関するセクションを参照してください。

ATL/MFC

ATL および MFC は比較的安定した API ですが、変更が行われる場合があります。 詳細については、Visual C++ 2003 から 2015 の変更履歴に関する記事、Visual Studio での Visual C++ の新機能に関する記事、Visual Studio の C++ 準拠の強化に関する記事を参照してください。

MSVCRTD.lib で既に定義されている LNK 2005 _DllMain@12

このエラーは MFC アプリケーションで発生することがあります。 CRT ライブラリと MFC ライブラリの間での順序付けの問題を示します。 最初に MFC をリンクして、new および delete 演算子が提供されるようにする必要があります。 このエラーを修正するには、/NODEFAULTLIB スイッチを使用して、既定のライブラリである MSVCRTD.lib と mfcs140d.lib を無視します。 次に、これらのライブラリを追加の依存関係として追加します。

32 ビットと 64 ビット

元のコードを 32 ビット システム用にコンパイルする場合は、新しい 32 ビット アプリの代わりに (またはそれに加えて)、64 ビット バージョンを作成することもできます。 一般には、まずプログラムを 32 ビット モードでコンパイルしてから、64 ビット モードでのコンパイルを試みてください。 64 ビットのコンパイルは単純ですが、場合によって、32 ビットのビルドで隠れていたバグが明らかになることがあります。

また、ポインター サイズ、時間とサイズの値、printf 関数と scanf 関数のサイズ固有の書式指定子に関連して発生する可能性のある、コンパイル時と実行時の問題にも注意する必要があります。 詳細については、64 ビットの x64 ターゲット用の Visual C++ の構成に関する記事、および「Visual C++ の 64 ビットへの移行に関する一般的な問題」を参照してください。 移行に関するその他のヒントについては、「64 ビット Windows プログラミング ガイド」を参照してください。

Unicode と MBCS/ASCII

Unicode が標準化される前は、多くのプログラムで、ASCII 文字セットに含まれていない文字を表すためにマルチバイト文字セット (MBCS) が使用されていました。 古い MFC プロジェクトでは、MBCS が既定の設定でした。 そのようなプログラムをアップグレードすると、代わりに Unicode を使用するよう勧める警告が表示されます。 Unicode への変換は開発コストに見合わないと判断した場合は、この警告を無効にするか無視してもかまいません。 ソリューション内のすべてのプロジェクトに対して警告を無効にするには、[表示]>[プロパティ マネージャー] の順に開き、警告を無効にするすべてのプロジェクトを選択し、選択した項目を右クリックして、[プロパティ] を選択します。 [プロパティ ページ] ダイアログ ボックスで、[構成プロパティ]>[C/C++]>[詳細] の順に選択します。 [指定の警告を無効にする] プロパティで、ドロップダウン矢印を開き、[編集] を選択します。 テキスト ボックスに「4996」と入力します (プレフィックス "C" を含めないでください)。[OK] を選択してプロパティを保存し、[OK] を選択して変更を保存します。

詳細については、「Porting from MBCS to Unicode」 (MBCS から Unicode に移植する) を参照してください。 MBCS と Unicode の一般的な情報については、「Visual C++ のテキストと文字列」および「国際化」を参照してください。

関連項目

旧バージョンの Visual C++ からのプロジェクトのアップグレード
Visual Studio の C++ 準拠の強化