.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
はい-常に適切だと思います。ユーザー固有の設定は他のファイルにあります。
はい、これを行う必要があります。ソリューションファイルには、ソリューションの全体的な構造に関する情報のみが含まれます。情報はソリューション全体に適用され、プロジェクトのすべての開発者に共通する可能性があります。
ユーザー固有の設定は含まれていません。
あなたは間違いなくそれを持っている必要があります。他の人々が言及した理由に加えて、プロジェクト全体のワンステップビルドを可能にする必要があります。
はい、コミットすべきことは次のとおりです。
- ソリューション（* .sln）、
- プロジェクトファイル、
- すべてのソースファイル、
- アプリ構成ファイル
- ビルドスクリプト
コミットする必要があるnotコミットは次のとおりです。
- ソリューションユーザーオプション（.suo）ファイル、
- 生成されたファイルをビルドする（ビルドスクリプトを使用するなど）[編集：]-必要なすべてのビルドスクリプトとツールがバージョン管理下で利用可能な場合のみ（ビルドを保証するため） cvs履歴で本物です）
他の自動生成ファイルについては、 個別のスレッド があります。
ソリューションファイルをチェックインする必要があることに私は一般的に同意しますが、私が働いている会社では別のことを行っています。かなり大きなリポジトリがあり、開発者は時々システムのさまざまな部分で作業します。作業方法をサポートするには、1つの大きなソリューションファイルまたはいくつかの小さなソリューションファイルを用意します。どちらにもいくつかの欠点があり、開発者側で手作業が必要です。これを回避するために、すべてを処理するプラグインを作成しました。
このプラグインにより、各開発者は、リポジトリから関連するプロジェクトを選択するだけで、ソースツリーのサブセットをチェックアウトして作業できます。次に、プラグインはソリューションファイルを生成し、指定されたソリューションのプロジェクトファイルをオンザフライで変更します。また、参照も処理します。言い換えれば、開発者がしなければならないことは、適切なプロジェクトを選択するだけで、その後、必要なファイルが生成/変更されます。これにより、他のさまざまな設定をカスタマイズして、会社の標準を確保することもできます。
さらに、さまざまなチェックインポリシーをサポートするためにプラグインを使用します。これにより、通常、ユーザーが欠陥のある/準拠していないコードをリポジトリに送信できなくなります。
はい、ソース管理の一部である必要があります。アプリケーションからプロジェクトを追加/削除するたびに、.slnが更新され、ソース管理下に置くとよいでしょう。これにより、アプリケーションコード2バージョンを引き出して、ビルドを直接実行できます（必要な場合）。
はい。常に.slnファイルを含める必要があります。これには、ソリューションに含まれるすべてのプロジェクトへのリンクが含まれます。
ほとんどの状況では、.slnファイルをソース管理にコミットすることをお勧めします。
.slnファイルが別のツール（CMakeなど）によって生成された場合、それらをソース管理に入れることはおそらく不適切です。
通常、ソリューションファイルはすべてソリューションディレクトリに配置します。このようにして、ソリューションをコードから少し分離し、作業する必要があるプロジェクトを選択するのが簡単になります。
すべての同期を保つためです。必要なプロジェクトはすべて一緒に配置されており、プロジェクトが見つからないことを心配する必要はありません。ビルドサーバー（Ant Hill Pro）もslnを使用して、リリース用にビルドするプロジェクトを計算します。
ソース管理に保存しないと考える唯一のケースは、ソース管理にある多くのプロジェクトで大規模なソリューションがあり、一部のメインソリューションからいくつかのプロジェクトで小さなソリューションを作成したい場合ですプライベート一時要件。
TFSバージョン管理でファイルを保持または解決します。しかし、メインソリューションは非常に大きいため、ほとんどの開発者は必要なものだけを含む個人的なソリューションを持っています。メインソリューションファイルは、主にビルドサーバーによって使用されます。
はい-製品の生成に使用されるものはすべてソース管理下にある必要があります。
.slnsのみがhave n't tfsで問題が発生しました！