Visual Studio Setup Project と vdproj→MSBuild移行 ― ComponentId の扱い

MSBuild だけでセットアップを組んでると、vdproj が残ってる環境だけ妙に重くなる場面があった。古い UI やアクションが入り組んだタイプのやつ。MSBuild は .vdproj を直接触れないので、中身を読んで MSI のテーブルに流し込む形で順に挙動を追った。

ComponentId を追っていくと、計算式を探す方向はすぐに意味がなくなる。vdproj に最初から GUID が固定で書かれていて、それを MSI の Component テーブルへ渡すだけ。ログを並べると、値が変わる理由は計算じゃなくて、vdproj の読み取り位置のズレ。MSBuild が拾うタイミングが少し違うだけで結果が変わる。ComponentId が後段で再計算される仕組みじゃないのは、当初の想定と違ったけど、確認できてよかった。vdproj の GUID を確実に取るように入力を整えると MSI の出力が安定する。実際には、vdproj の該当ブロックを固定順で読むようにしただけで、ローカルと Jenkins が揃う。Component テーブル → Jenkins のビルド結果まで一連で、扱い方の差がそのまま出力に反映されていた。

差の正体は計算ロジックじゃなくて、vdproj に保存されてる GUID をどの粒度で拾うかの構成の問題。既存 GUID をそのまま使うと VS と Jenkins の出力は一致する。確認した範囲では、この整理が一番再現性が取れた。MSBuild に寄せるなら、この位置の確認がいちばん安定する。