bindingRedirect の newVersion が、実在しないアセンブリの版を指している（8 件）

[OsscJpDevInfra]

概要

bindingRedirect の newVersion が、実際に配布されるアセンブリの版と食い違っている。

宣言した版がリポジトリのどこにも無いため、その範囲に入る要求は解決に失敗する。

#554（未使用・陳腐化した参照）で 1 件だけ見つかっていたが、
全体を洗ったら 8 件あったので、独立させる。

現状（実測）

追跡下の *.config から bindingRedirect を集め、
AssemblyName.GetAssemblyName() で得た実在するアセンブリの版と突き合わせた。

	件数
bindingRedirect の総数	847
一致	832
不一致（宣言した版が存在しない）	8
実体なし（そのアセンブリ自体がリポジトリに無い）	7

不一致の 8 件

場所	アセンブリ	宣言	実体
CS/Frameworks/Tests/TestCode/App.config	Newtonsoft.Json	10.0.0.0	13.0.0.0
CS/Frameworks/Tests/EncAndDecUtilCUI/App.config	Newtonsoft.Json	11.0.0.0	13.0.0.0
CS/Frameworks/Tests/TestBatch/SimpleBatch/app.config	Newtonsoft.Json	12.0.0.0	13.0.0.0
CS/Frameworks/Infrastructure/Public/Db/DamMySQL/app.config	Google.Protobuf	3.6.1.0	3.30.0.0 / 3.30.2.0
CS/Samples/WS_sample/WSClient_sample/WSClientWinCone_sample/app.config	Microsoft.Owin	4.0.0.0	4.2.2.0
CS/Samples/WS_sample/WSClient_sample/WSClientWPF_sample/app.config	Microsoft.Owin	4.0.0.0	4.2.2.0
VB/Samples/WS_sample/WSClient_sample/WSClientWin_sample/app.config	Microsoft.Owin	4.0.0.0	4.2.2.0
〃	Microsoft.Owin.Security	3.1.0.0	4.2.2.0

Newtonsoft.Json は 10 / 11 / 12 とバラバラで、単体テストの 3 プロジェクトすべてが該当する。
Google.Protobuf の乖離が最大（3.6.1.0 → 3.30.x）。

なぜ問題か

<bindingRedirect oldVersion="0.0.0.0-12.0.0.0" newVersion="12.0.0.0"/>

これは「0.0.0.0〜12.0.0.0 の要求が来たら 12.0.0.0 を読め」という意味である。
12.0.0.0 は配布されていないので、この範囲の要求は解決に失敗する。

今は動いている。それが厄介である

実体の 13.0.0.0 を要求するコードは、範囲外なので転送されず、直接束縛される。
つまり現状の組み合わせでは表面化しない。

古い版を要求する依存が 1 つ増えた瞬間に落ちる、という形で顕在化する。
0_RunAll.ps1 -Lang Both は通る（実測）。

Samples4NetCore/ANALYSIS.md 7 節との違い

同書 7 節は同じ「バージョンのずれ」でも別の現象なので、混同しないこと。

	net10.0（同書 7 節）	net48（本件）
bindingRedirect	仕組み自体が無い	ある
ずれると	即 FileNotFoundException で起動不能	**黙って通る。**条件が揃うと落ちる
直し方	サンプル側のパッケージ版を上げる	newVersion を実体に合わせる

net48 の方が見つけにくい。

対応（案）

① 実体に合わせる

機械的な置換で済む。8 件。

ただし bindingRedirect は NuGet の生成物である。
パッケージ操作（更新・再インストール）でまた書き換わるため、
直しても再発する。

② 検知の仕組みを持つ

#553 で入れた CompareConfig.ps1 と同じ考え方で、
ずれを検出できる状態にしておく方が本質だと考える。

今回の洗い出しはスクリプト 1 本で済んでいる。

1. リポジトリ内の *.dll から AssemblyName.GetAssemblyName() で版を集める
2. 追跡下の *.config から assemblyIdentity + bindingRedirect を集める
3. newVersion が、集めた版の集合に無いものを挙げる

リポジトリに入れるなら root/programs/CompareRedirect.ps1 あたり。
CompareConfig.ps1 と同じく合否を返す形にできる。

③ 何もしない（記録だけ）

現状は動いており、bindingRedirect は生成物である。
「再発するものを手で直す」ことの費用対効果は、確かに検討の余地がある。

影響

• 利用者への影響: 無し（現状の組み合わせでは動作が変わらない）。
  ただし将来の不具合の芽であり、直せば芽は消える
• net48 / net10.0: net48 のみ（bindingRedirect は net48 の仕組み）
• 検証: 0_RunAll.ps1 -Lang Both。
  ただし通ることは「直った」証拠にならない（直す前から通る）。
  確認は宣言と実体の突き合わせで行う

関連

• #554（未使用・陳腐化した参照。ここで 1 件見つけ、本件へ切り出した）
• #553（CS / VB の設定同期。VB の Newtonsoft.Json 3 件はそこで直した。
  CS / VB のずれとして現れたためで、本件の 8 件とは別）
• Samples4NetCore/ANALYSIS.md 7 節

[OsscJpDevInfra]

訂正 — 本文の「8 件」は、測り方が誤っていました

②（検知の仕組み）に着手したところ、起票時の測り方に欠陥があったと分かった。
数字が独り歩きしないよう、先に訂正する。

何を間違えたか

判定基準を **「宣言した版が、リポジトリのどこかに在るか」**にしていた。

これはビルドの状態で答えが変わる。

	CS/Frameworks/Tests/TestCode/App.config の Newtonsoft.Json 10.0.0.0
起票時（クリーン直後）	不一致（10.0.0.0 がどこにも無かった）
今回（ビルド後）	一致（TestCode\net48\bin\Debug\Newtonsoft.Json.dll が 10.0.0.0）

1_BuildAll.ps1 は bin を消す。測るタイミングで結果が変わっていた。

この Issue の主張（「通ることは正しさの証拠にならない」）を書きながら、
自分の測定が同じ穴に落ちていた。

正しい基準と、測り直した結果

そのプロジェクトの出力配下に在るアセンブリと突き合わせるべきである。
bindingRedirect はそのアプリが読む先を決めるものなので、
他のプロジェクトの bin に在るかどうかは関係がない。

測り直した。

場所	アセンブリ	宣言	配下の実体
CS/Frameworks/Tests/EncAndDecUtilCUI/App.config	Newtonsoft.Json	11.0.0.0	13.0.0.0	不一致
CS/Frameworks/Tests/TestBatch/SimpleBatch/app.config	Newtonsoft.Json	12.0.0.0	13.0.0.0	不一致
VB/Samples/WS_sample/WSClient_sample/WSClientWin_sample/app.config	Microsoft.Owin	4.0.0.0	4.2.2.0	不一致
〃	Microsoft.Owin.Security	3.1.0.0	4.2.2.0	不一致
CS/Frameworks/Tests/TestCode/App.config	Newtonsoft.Json	10.0.0.0	10.0.0.0 も在る	一致（誤検出だった）
CS/Frameworks/Infrastructure/Public/Db/DamMySQL/app.config	Google.Protobuf	3.6.1.0	—	判定不能
CS/Samples/WS_sample/WSClient_sample/WSClientWinCone_sample/app.config	Microsoft.Owin	4.0.0.0	—	判定不能
CS/Samples/WS_sample/WSClient_sample/WSClientWPF_sample/app.config	Microsoft.Owin	4.0.0.0	—	判定不能

8 件 → 不一致 4 件 / 誤検出 1 件 / 判定不能 3 件

「判定不能」は「問題なし」ではない。 そのプロジェクトの出力が無い
（ビルドしていない、または成果物を配らない構成）ため、材料が無いだけである。
ビルドしてから測り直せば判定できる。

もう 1 つの問題 — 遅すぎる

リポジトリ内の DLL を全部読む作りにしたため、7.3 分かかった。

	件数
DLL 総数	8,155
うち bin 配下	4,903
うち packages 配下	1,867
うち Build 配下	750

CompareConfig.ps1 は 4.5 秒である。0_RunAll.ps1 に組み込める速度ではない。

これからどうするか

CompareRedirect.ps1 は書いたが、この設計のままでは使えないので直す。

	直す内容
判定基準	「リポジトリのどこか」→ 「そのプロジェクトの出力配下」
速度	プロジェクト単位なら、その配下だけを見ればよい
組み込み位置	ビルド後でないと判定できない。 0_RunAll.ps1 の先頭ではなく、1_BuildAll.ps1 の後
「判定不能」の扱い	不一致には数えない。ただし件数は必ず出す（黙って 0 件にしない）

#553 の CompareConfig.ps1 -Check は
設定ファイルどうしの比較なのでビルドに依存しないが、
こちらはビルド成果物を見るため性質が違う。同じ形にはできない。

本文の扱い

本文の「8 件」の表は、この訂正で置き換わる。
本文を編集するか、このコメントを正とするかは、追って判断いただきたい。

[OsscJpDevInfra]

検知の仕組みを作り、24 件を直しました

件数がまた変わります。 3 回変わっているので、何をどう間違えたかから書く。

測り方の変遷

	基準	対象	不一致
本文（起票時）	リポジトリのどこかに在るか	全 41 config	8 件
前のコメント	そのプロジェクトの配下	上の 8 件だけ	4 件
今回	そのプロジェクトの配下	全 41 config	24 件

旧方式は、誤検出と見逃しの両方を出していた

• 誤検出：TestCode の Newtonsoft.Json 10.0.0.0。
  そのプロジェクトの bin に 10.0.0.0 が在り、正しかった
• 見逃し：Microsoft.Extensions.DependencyInjection.Abstractions の 8.0.0.2。
  CS/Frameworks/Infrastructure/Build/ に 8.0.0.2 が 24 個在るため
  「どこかに在る」を満たしてしまい、21 件を素通りさせていた

前のコメントは「旧方式が挙げた 8 件」を検算しただけなので、見逃し分は出てこなかった。
訂正の仕方が足りなかった。

CompareRedirect.ps1（新規）

.\CompareRedirect.ps1                     # 一覧
.\CompareRedirect.ps1 -Detail -Only Tests # 判定不能の内訳も
.\CompareRedirect.ps1 -Check              # 合否（不一致があれば 1）

判定基準	そのプロジェクトの配下（config の在るディレクトリ以下）。リポジトリ全体から探さない
速度	6.8 秒（最初の作りは 436.7 秒）。参照されている名前の DLL だけを読む。全部読むと 8,155 個になる
「判定不能」	不一致に数えない。ただし件数は必ず出す
対応	PowerShell 5.1 / 7 の両方で構文確認済み

直した 24 件

23 ファイル・24 挿入 / 24 削除（値の置換のみ）。

アセンブリ	宣言 → 実体	件数
Microsoft.Extensions.DependencyInjection.Abstractions	8.0.0.2 → 9.0.0.6	21
Newtonsoft.Json	11.0.0.0 → 13.0.0.0	1（EncAndDecUtilCUI）
Newtonsoft.Json	12.0.0.0 → 13.0.0.0	1（TestBatch/SimpleBatch）
Microsoft.Owin	4.0.0.0 → 4.2.2.0	1（VB/WSClientWin_sample）
Microsoft.Owin.Security	3.1.0.0 → 4.2.2.0	1（同上）

net48 の出力だけを見て決めた。 DaoGen_Tool などは net10.0 の出力が同居しており、
app.config が効くのは net48 側だけである。
全 24 件が一意に解決し、「候補が複数」「該当が一意でない」は 0 件だった。

1 件を手で検算した。

CS/Samples/Bat_sample/SimpleBatch_sample/app.config
  <bindingRedirect oldVersion="0.0.0.0-8.0.0.2" newVersion="8.0.0.2" />
  配下の実体 : bin\Debug\...\DependencyInjection.Abstractions.dll → 9.0.0.6

修正後、不一致 0 件 / ExitCode=0。

0_RunAll.ps1 に組み込みました

1_BuildAll.ps1 の直後に置いた。設定ファイルどうしを比べる
CompareConfig.ps1（先頭で実行）とは位置が違う。 こちらは
「そのプロジェクトが配布するアセンブリ」を見るため、ビルド前だと材料が無い。

#553 と同じく合否には影響させない（警告のみ、2 か所に表示）。

検証

.\0_RunAll.ps1 -Lang Both : すべて OK / ExitCode=0（3 本とも 0、警告なし）

★ 副産物 — 通しビルドの後、一部のサンプルの成果物が消えている

「判定不能 219 件」がビルド後も減らないので追ったところ、
1_BuildAll.ps1 が、直前にビルドした net48 サンプルの出力を消していた。

1_BuildAll.ps1 のステップ定義を見ると、Clean (net48 サンプル) と
Clean (core サンプル) は同じ CS\1_DeleteDir.bat を呼んでいる。

Clean (net48 サンプル)     1_DeleteDir.bat
2CS_sample (net48)         ← ここでビルド
Bat_sample (net48)
WS_sample (net48) ...
Clean (core サンプル)      1_DeleteDir.bat   ← **上でビルドした出力を消す**
2CSCore_sample ...

1_DeleteDir.bat は bin を含む（packages, obj, bin, bld, Temp, ...）うえ、
for /D /R でカレント（CS\）から再帰的に消す。

実測（-Lang Both の通し直後）。

	DLL / EXE
Samples/Bat_sample/SimpleBatch_sample	86 / 2	疎通テストが再ビルドするので戻る
Samples/2CS_sample/2CSClientWin_sample	0 / 0	疎通の対象外なので戻らない
Samples/WS_sample/WSClient_sample/WSClientWin_sample	0 / 0	同上

ビルドの合否には影響しない（各ステップは成功している）。
疎通も通る（対象は再ビルドされるため）。
しかし 1_BuildAll.ps1 を回した後、2CS_sample や WS_sample の exe は存在しない。

これは本件とは別の問題なので、別 Issue にするのが妥当と考える。文面は用意できる。

残ること

• bindingRedirect は NuGet の生成物である。 直しても、パッケージ操作でまた書き換わる。
  検知器を入れたのは、そのときに気付けるようにするためである
• 判定不能 219 件は上記のとおり。副産物の件が片付けば、実質は減る