【VS2026】LNK2005 / LNK1169: operator new 重複定義とライブラリ競合の直し方

2026年2月5日

古いプロジェクト（VS2010やVS2013時代）をVS2026で開くと、出力ウィンドウを埋め尽くす大量のリンクエラーが出ることがあります。

特に、operator new や _DllMain が重複しているという LNK2005 エラーは、MFCとCランタイム（CRT）の「どちらが先に場所を取るか」という、古くからある「椅子の奪い合い」が原因です。

この記事では、そんな歴史的な規律問題を解決し、気持ちよくビルドを通すための手順をまとめました。

エラーの原因切り分け：なぜ重複するのか？

エラー一覧に LNK2005 と LNK1169 が出ていたら、まずは以下の状況であることを確認してください。

エラー番号	現象	原因
LNK2005	`operator new` が `LIBCMTD.lib` で定義済み	リンク順序の逆転 CRTがMFCより先に読み込まれている
LNK1169	多重定義されたシンボルが見つかりました	上記の結果、全体の整合性が取れない

本来、MFCアプリには「MFCのライブラリをCRT（標準ライブラリ）より先にリンクしなければならない」という鉄の掟があります。

VS2026への変換時にこの順序設定がリセットされると、CRTが先に new を定義してしまい、後から来たMFC独自の new と衝突してエラーになります。

検証環境：Visual Studio 2026

以下、この順番で設定を強制的に上書きしていきます。

まずは、リンカが勝手に読み込んでいる（順序が間違っている）ライブラリを「無視」リストに放り込みます。

uafxcwd.lib;libcmtd.lib

注意

古い設定（マルチバイト/MBCS）の場合は、nafxcwd.lib;libcmtd.lib になります。エラーログに出ているライブラリ名に合わせてください。

無視したライブラリを、今度は手動で**「正しい順序（MFCが先）」**で登録し直します。

uafxcwd.lib;libcmtd.lib

ここが最大のポイントです。必ず MFCのライブラリ（uafxcwd/nafxcwd）を先頭 に書いてください。これで「MFCの new を優先しろ」とリンカに命令できます。

上記の設定でも直らない場合、ソースコード側（特にプリコンパイル済みヘッダー）でCRTを先に呼んでしまっている可能性があります。

stdafx.h（または pch.h）を開き、インクルード順序を確認してください。

× ダメな例（CRTが先）

#include <windows.h>  // CRT設定が先に読み込まれてしまう
#include <afxwin.h>   // ここでMFCを読んでも手遅れ

〇正しい例（MFCが先）

#include <afxwin.h>   // MFCが先にリンク指示を出す
#include <windows.h>

#include <afx...> がファイルの最上部にあることが重要です。

設定は完璧なはずなのにエラーが消えない場合は、古いビルド情報が悪さをしている可能性があります。

プロジェクトを右クリック → [クリーン]
エクスプローラーでプロジェクトフォルダを開き、隠しフォルダの .vs フォルダと、生成された x64 (または Debug/Release) フォルダを物理的に削除。
再度 [リビルド] を実行。

最後に、次回の自分のためにこれだけは確認しておきましょう。

MFCのビルドエラーは、コードのバグではなく「環境設定のパズル」であることが大半です。焦らず構成プロパティを確認して、パズルを解いていきましょう。