.slnはソース管理にコミットする必要がありますか？

.slnファイルをソース管理にコミットすることはベストプラクティスですか？そうすることが適切または不適切なのはいつですか？

更新 回答にはいくつかの良い点がありました。回答ありがとうございます！

他の回答から、ソリューションファイルは有用であり、公式ビルドに使用されていなくてもコミットする必要があることは明らかだと思います。これらは、Go To Definition / DeclarationなどのVisual Studio機能を使用するすべての人にとって便利です。

デフォルトでは、絶対パスやその他のマシン固有のアーティファクトは含まれていません。（残念ながら、AMD CodeAnalystなど、一部のアドインツールはこのプロパティを適切に維持しません。）プロジェクトファイル（C ++とC＃の両方）で相対パスを使用するように注意すると、それらはマシンに依存しなくなります。あまりにも。

おそらくより有用な質問は次のとおりです。どのファイルを除外する必要がありますか？これが私のVS 2008プロジェクトの.gitignoreファイルの内容です。

*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/

（最後のエントリーは、AMD CodeAnalystプロファイラー専用です。）

VS 2010の場合、次のものも除外する必要があります。

ipch/
*.sdf
*.opensdf

はい-常に適切だと思います。ユーザー固有の設定は他のファイルにあります。

はい、これを行う必要があります。ソリューションファイルには、ソリューションの全体的な構造に関する情報のみが含まれています。この情報はソリューション全体に適用され、プロジェクトのすべての開発者に共通です。

ユーザー固有の設定は含まれていません。

あなたは間違いなくそれを持っている必要があります。他の人が言及した理由に加えて、プロジェクト全体の1つのステップのビルドを可能にする必要があります。

ソリューションファイルをチェックインする必要があることに一般的に同意しますが、私が働いている会社では別のことをしました。かなり大きなリポジトリがあり、開発者は時々システムのさまざまな部分で作業します。作業方法をサポートするために、1つの大きなソリューションファイルまたはいくつかの小さなソリューションファイルを用意します。これらは両方ともいくつかの欠点があり、開発者側で手動の作業が必要です。これを回避するために、すべてを処理するプラグインを作成しました。

プラグインを使用すると、各開発者は、リポジトリから関連するプロジェクトを選択するだけで、ソースツリーのサブセットをチェックアウトして作業できます。その後、プラグインはソリューションファイルを生成し、指定されたソリューションのプロジェクトファイルをオンザフライで変更します。参照も処理します。言い換えれば、開発者がしなければならないことは、適切なプロジェクトを選択することだけであり、その後、必要なファイルが生成/変更されます。これにより、他のさまざまな設定をカスタマイズして、会社の標準を確保することもできます。

さらに、さまざまなチェックインポリシーをサポートするためにプラグインを使用します。これにより、ユーザーが誤ったコードや非準拠のコードをリポジトリに送信するのを防ぎます。

はい、あなたがコミットすべきことは：

• ソリューション（* .sln）、
• プロジェクトファイル、
• すべてのソースファイル、
• アプリ構成ファイル
• ビルドスクリプト

コミットすべきでないものは次のとおりです。

• ソリューションユーザーオプション（.suo）ファイル
• ビルドされたファイルをビルドする（ビルドスクリプトを使用するなど）[編集：] -必要なすべてのビルドスクリプトとツールがバージョン管理下で利用できる場合のみ（ビルドがCVS履歴で本物であることを確認するため）

他の自動生成されたファイルに関しては、別のスレッドがあります。

はい、ソース管理の一部である必要があります。アプリケーションからプロジェクトを追加/削除すると、.slnが更新され、ソース管理下に置くとよいでしょう。これにより、アプリケーションコード2のバージョンを元に戻し、直接ビルドを行うことができます（必要な場合）。

ほとんどの場合、.slnファイルをソース管理にコミットすることをお勧めします。

.slnファイルが別のツール（CMakeなど）によって生成されている場合、それらをソース管理に置くことはおそらく不適切です。

はい、常に.slnファイルを含める必要があります。ソリューションに含まれるすべてのプロジェクトへのリンクが含まれています。

すべての同期を保つためです。必要なプロジェクトはすべて一緒に配置されており、プロジェクトを見逃す心配はありません。ビルドサーバー（Ant Hill Pro）もslnを使用して、リリース用にビルドするプロジェクトを特定します。

通常、すべてのソリューションファイルをソリューションディレクトリに配置します。このようにして、ソリューションをコードから少し分離し、作業する必要があるプロジェクトを選択するのが簡単になります。

ソース管理にそれを格納しないことを検討する唯一のケースは、ソース管理にある多くのプロジェクトを含む大規模なソリューションがあり、いくつかのメインソリューションからいくつかのプロジェクトを含む小さなソリューションを作成したい場合です。一時的なプライベート要件。

はい-製品の生成に使用されるすべてのものをソース管理する必要があります。

TFSバージョン管理でファイルを保持または解決します。しかし、メインのソリューションが本当に大きいため、ほとんどの開発者は必要なものだけを含む個人的なソリューションを持っています。メインソリューションファイルは主にビルド​​サーバーによって使用されます。

.slnは、tfsで問題が発生していない唯一の問題です。