slnファイルの役割とcsprojとの違い
C#でプロジェクトを作成すると、いっしょにソリューションファイル（sln）が作成されます。
Visual Studioから開くために使うくらいで、ほとんどソリューションファイルを使わない人もいるでしょう。
このソリューションファイルは何のためにあるのでしょうか。
そこで今回は
「ソリューションファイルとプロジェクトファイルの違い」
「ソリューションファイルができること」
「ソリューションファイルが有効な場面」
「ソリューションファイルの使い方」
について紹介したいと思います。
目次
【.slnファイル】自分のプロダクトを一元管理する仕組み
.slnファイルは複数のコードを一元管理するための仕組みです。
管理する方法は以下です。
- 複数のプロジェクトをまとめる
- 様々の種類のプロジェクトを管理できる
- プロジェクト間共有ができる
- NuGetを一括管理できる
まずは.slnファイルと.csprojとの違いから見ていきましょう。
.slnファイルは.csprojファイルをまとめるもの
最初に.slnファイルの役割から明確にしましょう。
結論からいうと.slnファイル（ソリューション）は.csprojファイル（プロジェクト）を一括管理するための仕組みになります
実際にVisual Studio上でソリューションファイルに複数のプロジェクトをひもづけるとこんな感じになります。
ひとつのソリューションファイルに3つのプロジェクトが紐づいていますね。
様々な種類のプロジェクトを管理できる
先ほどの画像にもあるように、コンソールアプリ、WEBアプリ、ライブラリを
ひとつのソリューションファイルで管理できます。
他にもWindowsアプリなど、ほかのプロジェクトもソリューションファイルに組み込むことができます。
決してコンソールアプリならコンソールアプリだけで構成する、などの制限はありません。
製品・サービスは複数の種類のプログラムで動く
製品やサービスを作ろうとしたとき、単一のプログラムだけでつくれないこともよくあります。
WEBアプリで画面を表示して、日次バッチでデータを集計するなどです。
この場合、二つのプログラムが合わさって一つのサービスになります。
どちらかが欠けてもサービスにはなりません。
大量のデータを管理する製品やサービスでは珍しくはないですね。
このように複数のプログラムでサービスを構成しているときこそ、
ソリューションファイルの出番というわけです。
ソリューション内ではプロジェクトを共有できる
それでは、ソリューションファイルで管理することで、使用できる機能プロジェクト共有について紹介します。
簡単にプロジェクト間で共有できる
プロジェクトが増えてくると、プロジェクトをまたいで共通化したい処理がでてきます。
そんなとき、活躍するのがプロジェクト参照です。
ライブラリプロジェクトを用意することで複数のプログラムで共通の処理を一か所にまとめられます。
NuGetサーバーを使わなくても共有できる
ソリューションファイルを使わずにプロジェクトを共有する方法にNuGetがあります。
ただし、全世界にむけてサービスを使ってもらうための仕組みをアップすることになりますので注意が必要です。
より多くのひとに使用してもらえるのであれば、NuGetで共有する価値があります。
例えばSendGrid（メール送信サービス）のクライアントライブラリのようなものです。
しかし、自分たちのプログラムの中だけで共有したい機能であれば、
わざわざNuGetを利用しなくてもよいのではないでしょうか。
ソリューションでの「プロジェクト参照」を使えば実現できます。
プライベートNuGetを用意せずに共有できる
それは「公開NuGetサーバーを使っているからで、プライベートNuGetサーバーを用意すれば解決できる」という意見もあるかもしれません。
確かにNuGetサーバーを自前で用意すれば、非公開で共有することができます。
しかし、ソリューションファイルを用いれば、そもそもNuGetサーバーを用意する手間はいりません。
ソリューションの仕組みを使えば、非公開かつ低コストで共有プログラムを共有することができます。
配下のプロジェクトのNuGetを一元管理
先ほどはNuGetにアップロードとの比較をしました。
つぎにNuGetを通してサードパーティ製の機能をダウンロードし、利用することについてみていきましょう。
複数のプロジェクトのNuGetを串刺しで管理
ソリューションファイルを使えば、複数のプロジェクトを一括でNuGet管理できます。
各プロジェクトがどのようなサードパーティライブラリを使っているのか把握するのに便利です。
使用しているバージョンをそろえることができます。
バージョン競合の弊害を減らせる
また、一元管理をしておけば、バージョン違いによる不具合を防げるかもしれません。
ソリューション配下のプロジェクトはお互いをインポートできる関係です。
NuGetによる管理をしないで直接ライブラリを参照している場合で考えます。
例えば、同じサードパーティライブラリを使用しているに、
別のバージョンのライブラリを使っているプロジェクトをインポートしてしまうとどうなるでしょう。
プロジェクトAで利用しているサードパーティライブラリメソッドの結果と
プロジェクトBから利用する場合の結果が最悪、変わる可能性があります。
そうなれば、コードの組み方次第ではバグが発生してしまいます。
しかしNuGet管理をしておけば、下記のように
事前にバージョン違いによるミスを減らすことができます。
規模の小さい開発ではソリューションファイル管理だけで十分
新しくサービスをスタートさせるときには、小規模で始めるのは定石のひとつです。
小規模であれば、複雑な管理は不要で管理コストをおさえることで生産性がでます。
ソリューションファイルによる管理はどちらかというと小規模と相性が良いです。
理由を確認していきましょう。
集中管理は小規模プロダクト・サービスと相性が良い
ソリューションファイルはどちらかというと集中管理
ソリューションは集中管理を得意としています。
プロジェクトを共有することで、同じ機能を複数のプログラムで共有することができ、
共有されているプロジェクトの変更はすぐに反映されます。
「共有」していることからも、分散して管理すること逆のことをやっていますね。
ゆえに、ソリューションは集中管理の機能を持つことがわかります。
集中管理できるものを分散すると非効率になる
管理コストでみたとき、集中管理＜分散管理です。集中管理のほうが手間が少なく管理することができます。
たとえば、分散管理するために、NuGetサーバーを利用して共有機能を配布する仕組みをつくるとしましょう。
コンパイルしアップする作業が必要ですね。
非公開の機能であれば、自分たちで専用にNuGetサーバーを用意する手間もかかります。
CICDの仕組みを一度作れば手間は削減できるという意見もあるでしょう。
ですが、CICDも一度作って完成ではなく、維持するための管理も必要ですね。
ソリューション使っていればそういった手間がそもそも必要ありません。
バージョン管理もGitのソースコード管理だけで済みます。まさに低コストです。
複雑な分散管理は大規模開発で力を発揮する
大規模の開発は、複数の開発チームが同時に動くことになります。
そして、複数のチームがそれぞれ動くことのできる状況が最もパフォーマンスがでます。
しかし、この時に複数のチームを一極集中でソリューション管理してしまうと、
「開発待ち」などコードを書きたくても書けない状況がでてきます。
この「開発待ち」はクリティカルパスとも言い換えられますね。
10チームあるのに実質1チームしか動けないというパターンがあるということです。
しかし、分散管理がうまくいくと複数のチームが動けないといことをなるべく減らすことができます。
分散管理の手間を差し引いても、複数のチームを稼働させていたほうが全体の生産性があがるので、
大規模開発では集中管理より分散管理のほうが効率が良くなります。
大規模開発では分解してからがソリューションファイルの出番
それでは、大規模開発でソリューションファイルを利用した管理がダメなのか
といわれるとそんなことはありません。
大規模であれば分散管理と集中管理を併用します。
分散した結果、集中管理できるレベルにおちればそこでソリューション管理を検討します。
これ以上細切れにしたら管理が煩雑なるというところでソリューションの出番です。
ソリューションファイルの具体的な使い方
これまでソリューションファイルの役割や特徴について紹介しました。
次は、実際にソリューションファイルをvisual studioから操作する方法を見ていきましょう。
- ソリューションの中でプロジェクトを共有化する方法
- NuGet管理の方法
- 実行とデバッグ方法
ソリューションの中でプロジェクトを共有化する方法
プロジェクトを共有化には、「プロジェクトの参照追加」から追加できます
追加したいプロジェクトを選択して
インポートしたいソリューション配下のプロジェクトを選択してOKボタンを押下すれば完了です。
NuGet管理の方法
ソリューションを右クリックで「ソリューションのNuGetパッケージの管理」を開きます
参照タブから必要なパッケージを選んで
右側に出てくる対象のプロジェクトを選んでインストールします。
NuGet操作についてはこちらでも紹介しています。興味があればご覧ください。
実行とデバッグ方法
ソリューションは複数のプロジェクトをもっているので、単体のプロジェクトだけ実行・デバッグができますし、
複数のプロジェクトを同時に実行・デバッグすることができます。
指定したプロジェクトを実行する方法
スタートアッププロジェクト指定する
一番わかりやすいのは実行ボタンの横にあるプロジェクト選択から選んで、実行ボタンを押すだけです。
プロジェクトから実行【追加実行】
プロジェクトを右クリックするとデバッグの項目がでます。
ここから新しいインスタンスの開始をクリックすればデバッグが可能です。
このままだとスタートアッププロジェクトを指定することとなにもかわらないですよね。
しかし、この実行方法は追加実行が可能です。
すでにWEBアプリが立ち上がっている状態でも、追加でコンソールアプリを起動するときにこの方法が活躍します。
複数のプロジェクトを同時実行
複数のプロジェクトがあるのに一つずつ追加で実行するのはメンドクサイこともあります。
そんな時にはマルチスタートアップ設定に切り替えることで同時起動してしまいましょう。
まずは、ソリューションを右クリックしてスタートアッププロジェクトの設定をクリックします。
マルチスタートアップを選択し、デバッグを行いたいプロジェクトのアクションを「開始」に設定します。
起動すればWebもコンソールも全部立ち上がります。
もし起動順序があるのであれば、横についている上下ボタンで移動させてみてください。
まとめ
最後にまとめます。
- ソリューションはプロジェクトをまとめて管理することのできる仕組み
- ソリューションは集中管理と相性の良い、小規模の開発と相性がよい
- ソリューションを使えば複数のプロジェクトを同時に起動・デバッグできる
これにてソリューションの使い方の紹介は以上です。
ソリューションファイルがC#でコード書くときになんとなく作られるファイルから、
便利そうな仕組みだなと思っていただけたら幸いです。
