MS_Build

ビルド

• 戻る（CI）
  • ビルド
  • ビルドスクリプト（MS_BuildScript.md） / CI/CD

概要

ビルドに関するエトセトラ。

詳細

構成

構成とビルドは関連が深いですね。

プロジェクト・ソリューションの構成

• VSソリューション プロジェクトの構成検討（MS_VSSolutionStructure.md）
• ASP.NETの構成（Webサイト・Webアプリ）（MS_ASPNETProjectTypes.md）

フォルダ構成

• 「プロジェクト・ソリューションの構成」の影響を受ける。
• ビルド環境と開発環境のソースファイルパスを一致させる（PDB）。（MS_PDBSourcePath.md）

構成管理ツール

構成管理ツール（MS_ConfigurationManagementTools.md）

管理された構成をビルドするので、構成管理は重要です。

• 古き良き大規模 SI では「SI 班」なんて言う
  入出庫・ビルドする専門部隊が居たりしました。

• 流石に、もう SI 班は無いかと思いますが、
  それに反して、構成管理の重要性は高まる一方だと思います。

補足（なぜ構成管理が重要度を増したか）: 「SI 班」が担っていた
「誰が・いつ・何をビルドしたか」を保証する役割は無くなったのではなく、
仕組みに置き換わったというのが実情である。

当時（人手）	現在（仕組み）
SI 班が入出庫を管理	Git のブランチ戦略とプルリクエスト
専用マシンでビルド	CI サーバでのビルド（CI）
手順書どおりに実行	ビルド定義をコード化（YAML）
ビルド結果を台帳に記録	ビルド番号・成果物・ログの自動保管

「ローカルではビルドできるが CI では失敗する」を防ぐため、
CI でのビルドを唯一の正とするのが現在の原則である。

ビルドスクリプト

ビルドスクリプト（MS_BuildScript.md）で自動化をすると、
かなり生産性向上に寄与します。

• Visual Studio（ビルドスクリプト（MS_BuildScript.md））
• MSBuild（MS_MSBuild.md）
• NuGet（MS_NuGet.md）

補足（最新化：現在のビルド コマンド）: .NET Core 以降は、
dotnet CLI がビルド・テスト・パッケージ化の入口になっている
（内部的には MSBuild が動く）。

dotnet restore          # NuGet パッケージの復元
dotnet build -c Release # ビルド
dotnet test             # テストの実行
dotnet publish -c Release -o out

dotnet build は復元も暗黙に行うため、
CI では --no-restore / --no-build を明示して
同じ工程を二度走らせないようにするのが定石。

また、以下は現在のビルドで押さえるべき点である。

論点	内容
再現可能なビルド	global.json で SDK を固定し、packages.lock.json で依存を固定する
中央管理	Directory.Build.props / Directory.Packages.props で共通設定・バージョンを 1 か所に
警告をエラーに	TreatWarningsAsErrors で品質を担保（FxCop / StyleCop）
決定論的ビルド	ContinuousIntegrationBuild=true でパスを正規化（PDB の問題も解消）

参考

• MSBuild | Microsoft Learn
  https://learn.microsoft.com/ja-jp/visualstudio/msbuild/msbuild
• dotnet build コマンド
  https://learn.microsoft.com/ja-jp/dotnet/core/tools/dotnet-build

関連

• CI / CD / CI/CD パイプライン
• Jenkins

---

Tags: 移行, テスト, デバッグ, デプロイ, CI, .NET開発