[解決済み] .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