【MFC】LNK1104 で mfc120.lib / mfc140.lib を開けない：原因の切り分けと要求元 lib の特定

2026年2月19日2026年10月1日

LNK1104: mfc120.lib / mfc140.lib が見つからない時の連鎖依存特定法

古いプロジェクトをVisual Studio 2026でビルドすると、LNK1104: cannot open file ‘mfc120.lib’ やmfc140.libのエラーが出ることがあります。

mfc140.libはVisual Studio 2015以降の今のMFCの名前です。これが開けないなら、古い依存を探す前にMFCコンポーネントとライブラリディレクトリを確かめるのが基本です。mfc120.libのような古い名前が設定にもコードにも無いのに要求されるときは、リンクしている別の .libなどに古いMFCの指定が残っており、どれが要求元かは /VERBOSEのログで特定できます。

原因切り分け：なぜ「書いていない」mfc120.libが要求されるのか

まず、同じLNK1104でも原因を分けて考えます。

エラーに出た名前	状況	最初に疑う場所
mfc140.lib / mfc140u.lib（d付きも）	今のMFCのライブラリが見つからない	Visual Studio InstallerのMFCコンポーネント（使っているtoolsetとプラットフォームの分）、VC++ ディレクトリ
mfc120.libなど古い版が、追加の依存ファイルに書いてある	プロジェクト自身が古いMFCを指定している	リンカー > 入力 > 追加の依存ファイル
mfc120.libなど古い版が、設定にもコードにも無い	リンクしている外部 .lib（または既存の .obj）が古いMFCを要求している	/VERBOSEで「どの .libが要求したか」を特定する

MFCコンポーネントの追加手順はMSB8041の記事にあります。この先の手順では、表の3行目（リンクしているライブラリの中に、古い環境の既定ライブラリ指定が埋め込まれているケース）を追います。

C++ では #pragma comment(lib, “…”) によって、ライブラリ検索レコードがオブジェクトに埋め込まれます。リンカーはその記録を見て、コマンドラインで指定されたのと同じように追加ライブラリを探します。

#pragma comment(lib, "mfc90u.lib")

MFCのヘッダも同じ仕組みを使っていて、MFCを共有DLLで使う設定ではafx.hがこの指定でmfc140u.libなどを要求します。そのため、今のMFCの名前は設定に書いていなくてもエラーに出ます。同じように、あなたのプロジェクト側にmfc120.libが書かれていなくても、リンクした別ライブラリの内部に古い指定が残っていれば、リンカーは律儀にそれを探しに行きます。

この記事の再現ログは、Visual Studio 2026で、VS2008世代のMFC既定ライブラリ指定（mfc90u.lib）を内部に持つスタティックライブラリをリンクして取得したものです。

手順1：まずは /VERBOSEを有効にする

原因を特定するには、リンカーに「どのライブラリを、どの順で読み込んだか」を出させる必要があります。

対象プロジェクトの プロパティ を開きます。
リンカー > 全般 を開きます。
進行状況の表示 を 詳細情報をすべて表示 (/VERBOSE) に変更します。
その状態で リビルド します。

Visual Studio 2026のリンカー設定「進行状況の表示」で「詳細情報をすべて表示 (/VERBOSE)」を選ぶドロップダウンが開いている画面

/VERBOSEにすると、出力ウィンドウに「どのライブラリを読み込み、どの /DEFAULTLIB指定を処理したか」が流れます。似た設定に検索されたライブラリ (/VERBOSE:Lib) もありますが、「どの .libが要求したか」は /DEFAULTLIBを処理した行から読むので、/VERBOSEを選びます。

手順2：出力ウィンドウで「要求した側」を見つける

ビルドが失敗したら、エラー一覧ではなく出力ウィンドウ を見ます。目的は、mfc120.libのような古いMFCのlibを誰が要求したかを特定することです。

Ctrl + Fで、エラーに出たファイル名（今回ならmfc90u.lib）を検索します。
/DEFAULTLIB:mfc90u.libオプションで処理を行いました。の行を探します。
その直前にある ○○.lib(○○.obj) を読み込みました。の行とセットで読みます。

OldLib.lib を検索中:
  （中略）
  OldLib.lib(OldLib.obj) を読み込みました。
/DEFAULTLIB:mfc90u.lib オプションで処理を行いました。
  （中略）
LINK : fatal error LNK1104: ファイル 'mfc90u.lib' を開くことができません。

OldLib.libを読み込んだ結果、その内部にある /DEFAULTLIB:mfc90u.lib指定が処理され、古いMFCライブラリを探しに行って失敗した、という並びです。要求元は、/DEFAULTLIB:mfc90u.libを処理した行の直前に読み込まれたOldLib.libです。エラーの行の直前には別のライブラリが並ぶことがあるので、/DEFAULTLIBの行から見ます。

調査が終わったら「進行状況の表示」は「設定なし」に戻してください。ログが増え、通常のビルドでは見づらくなります。

手順3：修正フローを選ぶ

要求元の .libが分かったら、次の順に対処を考えます。

ソースがあるなら、依存ライブラリを現行環境でリビルドする
ソースに #pragma comment(lib, “mfc90u.lib”) のような古いライブラリ名が直接書いてあれば、先にそれを消してからリビルドします。現行のtoolsetとMFC構成で揃います。
プロジェクト全体を古いtoolsetのままビルドする
Visual Studio 2013以前のbuild toolsで作ったlibは、別の版のbuild toolsで作ったものと混ぜてリンクできません。リビルドできないlibに合わせるなら、プロジェクト全体をそのlibと同じtoolset（mfc120.libならVisual Studio 2013のv120）でビルドします。そのtoolsetが入っていないときに出るMSB8020はMSB8020の記事で扱っています。
サードパーティ製なら、提供元から新しいビルドを入手する
バイナリしかない場合は、Visual Studio 2015以降のbuild toolsで作られた版へ差し替えます。その範囲のlibは、原則としてVisual Studio 2026でリビルドせずにリンクできます。ただし、リンクする側のbuild toolsはlibを作った版以上であることが条件で、/GLや /LTCGを使って作ったlibは同じbuild toolsでないとリンクできません。

注意：Ignore Specific Default Librariesで古いMFCを無理に外して通す方法は、調査用には使えても、本番の修正としては安全とは限りません。依存ライブラリが本当にその版のMFCを前提に作られているなら、リンクが通っても実行時に別の問題になります。