• 戻る（.NET開発）

Visual Studio の、「ソリューション」・「プロジェクト」の構成を検討する際の
ポイントについて説明する。

Visual Studio では、開発するプログラムを、
ソリューション・プロジェクトという単位で管理する。

• １つのプログラムは、１－複数のアセンブリ（EXE や DLL ファイル）から
  構成される場合がある。

• １つの Web サイト・Web アプリケーションも、
  １－複数のアセンブリやコンテンツ ファイルから構成される。

• また、各アセンブリをコンピュータにインストールするための
  「セットアップ プログラム」・「Web セットアップ プログラム」などがある。

補足（3 つの単位の対応関係）: 混乱しやすいので先に整理する。

ソリューション（*.sln）      … 1 つ以上のプロジェクトを束ねる「作業単位」
  └ プロジェクト（*.csproj） … 1 つのアセンブリを作る「ビルド単位」
       └ アセンブリ（*.dll） … 1 つの「配置・バージョン管理単位」

原則 1 プロジェクト = 1 アセンブリであり、
ソリューションはビルドはするが、成果物そのものではない。
.NETアセンブリ も併せて参照。

• プロジェクトのビルドに関する構成情報を保持している。
• １つのアセンブリを作成するには、１つの「プロジェクト」が必要になる。
• １つの基本的なプロジェクトは１つのアセンブリを出力する（EXE、DLL）。

• *.csproj（C# 用）、*.vbproj（VB 用）などの拡張子を持つ。

• Windows アプリケーションの VB プロジェクトのプロパティの例

  • アプリケーション

    • アセンブリ名
    • 名前空間
    • アプリケーションの種類
    • アイコン
    • スタートアップ フォーム
    • フレームワーク
    • プロパティ
    • ,etc.

  • コンパイル

    • ビルド出力パス
    • 詳細コンパイル オプション
    • Option Explicit,Strict,Compare
    • 警告・エラーの表示
    • ,etc.

  • デバッグ
    デバッグ時の動作の設定をする。

    • スタートアップ
    • コマンドライン引数
    • ,etc.

  • 参照
    アセンブリや COM コンポーネントなど、
    プロジェクトで使用するコンポーネントの参照設定を設定する。

  • リソース
    プロジェクトのリソースを設定する。

    • 文字列
    • イメージ
    • アイコン
    • オーディオ
    • ファイル
    • ,etc.

  • 設定
    app.config のユーザ セッティング情報を設定する。

  • 署名
    アセンブリに厳密名などのアセンブリ署名をしたりする。

  • セキュリティ、発行
    ClickOnce アプリケーションで使用する設定をする。

補足: これらの設定は、いずれも MSBuild の
プロパティとして .csproj に書かれる。
GUI はその編集画面に過ぎない。
SDK 形式のプロジェクトでは .csproj が非常に短くなったため、
直接編集する方が速い場面も多い。

• モジュール単位の変更
• 配布単位の変更（アセンブリでの配布）

• 全体のビルドに関する構成情報を保持している。

• 複数のアセンブリから構成されるアプリケーションを作成できる。

• このような構成を行う場合、以下の２通りの方法がある。

  • 複数のアセンブリをプロジェクトでまとめる（バイナリ参照）。
  • 複数のプロジェクトをソリューションでまとめる（プロジェクト参照）。

• *.sln の拡張子を持つ。

• ソリューションのプロパティの例

補足（最新化）: .NET SDK 10 以降では、
*.slnx という新しい XML 形式のソリューション ファイルが導入された。
従来の .sln は独自形式で GUID が多く、
マージ コンフリクトが起きやすいという問題があったが、
.slnx はプロジェクトのパスを列挙するだけの素直な XML になっている。

<Solution>
  <Project Path="src/App/App.csproj" />
  <Project Path="src/Lib/Lib.csproj" />
</Solution>

• ビルド単位の変更
• 配布単位の変更（MSI での配布）

一般的に小規模開発の場合は分割を少なくして、大規模開発の場合に分割を検討する。

• 管理が容易になる。

• 開発作業の分担が可能になる。

• 部品化等により差し替えが容易になる。

• 修正箇所毎、ビルド範囲を絞る事ができる。

• アセンブリや MSI での配布が容易。

• プロセス、アプリケーション ドメイン分割により、
  障害範囲を少なくできる。

• 管理が煩雑になる。

• 開発作業の分担ができなくなる。

• 部品化等により差し替えができなくなる。

• 修正箇所毎、ビルド範囲を絞る事ができなくなる。

• 複数のアセンブリや MSI を
  組み合わせた配布が必要になる。

• プロセス、アプリケーション ドメイン分割により、
  プロセス間通信が必要になる。

補足（この表の読み方）: メリットとデメリットが
同じ項目の裏返しになっている点が要点である。
原文は「分割しない場合のデメリット」を並べているのではなく、
分割しすぎた場合のデメリットを並べていると読むのが正しい。

分割しない ◀──────────────────▶ 分割しすぎ
 ・ビルドが遅い                    ・管理が煩雑
 ・差し替えできない                ・参照関係が追えない
 ・分担しにくい                    ・ビルド順序が複雑

補足（実務上の目安）: 現在の一般的な指針は
**「プロジェクトは少ないほど良い」**である。

• プロジェクト数はビルド時間に直結する（1 プロジェクト = 1 コンパイル）
• アセンブリ境界は実行時のコストでもある（型のロード、JIT）
• 「レイヤごとにプロジェクトを分ける」だけでは設計上の意味が薄い
  （フォルダと internal で足りることが多い）

分けるべき明確な理由があるときにだけ分ける、というのが原則。

分ける理由	例
別々に配布する	NuGet パッケージにする、他システムへ提供する
参照の向きを強制したい	ドメイン層がインフラ層を参照しないことを保証する
ターゲットが違う	一方は netstandard2.0、他方は net8.0
テストプロジェクト	本体と一緒に配布しない

• Web アプリケーション、Web サイト毎に
  アプリケーション ドメインは異なる。
• Web アプリケーション、Web サイト
  （アプリケーション ドメイン）を格納するワーカプロセス（プロセス）を選択できる。

補足（最新化）: アプリケーション ドメインは
.NET Core 以降存在しない（作成できない）。
以下は .NET Framework ＋ IIS 前提の話である。

	.NET Framework	.NET（Core 系）
分離の単位	AppDomain（1 プロセス内で複数）	プロセス
アセンブリのアンロード	AppDomain 単位で可能	AssemblyLoadContext で可能
Web の分離	IIS のアプリケーション プール ＋ AppDomain	プロセス（Kestrel）単位

ASP.NET Core では 1 アプリ = 1 プロセスが基本であり、
分離はコンテナやアプリケーション プールの粒度で考えることになる。

• Server.Transfer は不可能。
• Response.Redirect, Link などの Get メソッドは可能。
• クロスページ ポストバックなどの POST メソッドは可能。

以下の状態管理技術は、異なるアプリケーション ドメインと情報共有できない。

• Application オブジェクト

• 静的変数

• Cache オブジェクト

• Session オブジェクト

• その他

  • ViewState は同一 WebForm 画面内でのみ有用。
  • HttpContext は、Server.Transfer 画面遷移の間で有用

以下の状態管理技術は、異なるアプリケーション ドメインと情報共有できる。

• QueryString
• Cookie
• Hidden
• Cookie 認証チケット
  ASP.NET2.0 から ASP.NET の Forms 認証の認証チケットを
  • 複数のサイト間で共有する仕組みが用意され、
  • 複数のサイト間で利用できるようになった。

各状態管理技術については、コチラを参照。

補足（この分類の本質）: 共有できるものとできないものの違いは、
どこに状態が置かれているかで決まる。

【共有できない】サーバのメモリ（プロセス内）に置く
   Application / 静的変数 / Cache / Session（InProc）

【共有できる】クライアントが持ち運ぶ
   QueryString / Cookie / Hidden / 認証チケット

したがって Session も「外に出せば」共有できる。
SQL Server セッション ステート、Redis（分散キャッシュ）を
使えばプロセスをまたげる。
これは .NET CoreのDockerコンテナ化 で述べた
「コンテナは複数インスタンスに増えるので状態を外出しする」
という話とまったく同じ構図である。

• プロジェクトに対して参照設定を行う。

• ビルド順も自動的に管理され、バージョンの不一致などが起こり難く使い易い。

• 参照先のプロジェクトの変更・差し替えが容易なので、
  FIX していないモジュールに対してはプロジェクト参照を使用する。

• アセンブリに対して参照設定を行う。

• 参照先のバイナリの変更・差し替えが面倒なので、
  FIX したモジュールに対してはバイナリ参照を使用する。

補足（現在は 3 つ目の選択肢がある）: 「FIX したかどうか」で
使い分けるという原文の整理は妥当だが、
現在は NuGet の PackageReference が
バイナリ参照の上位互換として使える。

方式	向く場面	依存の解決
プロジェクト参照	同じソリューション内。同時に開発する	ビルド順が自動
バイナリ参照（HintPath）	手元の DLL を直接指す	手動（推移的依存も自分で）
PackageReference	別リリース サイクルの共通部品	自動（推移的依存も解決）

バイナリ参照は推移的依存を自分で管理する必要があるため、
現在は NuGet 化するのが素直である
（社内なら NuGet プライベート・リポジトリ）。

• １つの Web アプリケーション・Web サイトは、
  １つの IIS のアプリケーションと対応する。
• 複数の Web アプリケーション・Web サイトを
  １つの IIS のアプリケーションに纏めることはできない。

１つの Web アプリケーション・Web サイトを複数プロジェクトにまとめる方法

裏ワザ的な方法だと思いますが・・・、

• マイクロソフト サポート オンライン
  チーム開発用に複数のプロジェクトから ASP.NET アプリケーションを作成する方法
  http://support.microsoft.com/default.aspx?scid=kb;ja;JP307467

補足（最新化）: ASP.NET Core では
Razor クラス ライブラリ (RCL) により、
View やページ、静的ファイルを別プロジェクトに置いて合成できる。
原文が「裏ワザ的」としていた構成が、標準機能になった。

WebApp.csproj      … ホスト
  └ 参照 Feature.A.csproj（RCL）… Views / wwwroot を含む
  └ 参照 Feature.B.csproj（RCL）

上記のようにサイトを纏めなくても、SessionCookie、Cookie 認証 Ticket が共有できれば。

• Web サイトを本番環境に配置する方法には、

  • ファイル・フォルダのコピー
  • プリコンパイル後のファイル・フォルダのコピー
  • セットアップ プログラムによるインストール

  などがある。

• Web アプリケーションを本番環境に配置する方法には、

  • 発行、Web Deploy
  • セットアップ プログラムによるインストール

  などがある。

• アセンブリが生成されていない状態でアプリケーションを配布した際の
  初期要求時に JIT コンパイルが実行される。
• JIT コンパイルによりアセンブリが生成され、その後にアプリケーションが実行される。
• JIT コンパイルにより生成されたアセンブリは、
  %windir%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files で確認できる。

• 事前コンパイルによりアセンブリを生成しておくことで
  初期要求時の JIT コンパイルを不要にできる。
• この場合、Web サイトのファイル システム上にアセンブリが生成される。
• プリコンパイルにより生成されたアセンブリは、
  生成された Web サイトのフォルダの直下にある「bin」フォルダで確認できる。

補足（Web サイトと Web アプリケーションの違い）: この節が
2 つを分けて説明しているのは、プロジェクトの種類が違うためである。

	Web サイト	Web アプリケーション
プロジェクト ファイル	無い（フォルダがそのままプロジェクト）	ある（.csproj）
コンパイル	実行時（初回要求時に JIT）	ビルド時（1 つの DLL に）
配置	ソース（.aspx.cs）ごとコピー	bin の DLL ＋ .aspx

Web サイト形式はソース コードが本番に置かれるため、
セキュリティ・性能の両面で現在は使われない。
詳細は ASP.NETの構成（Webサイト・Webアプリ）を参照。

Web セットアップ プログラムによる Web サイトのインストールが可能。

---

Tags: 移行, .NET開発