visual-studio - .sln をソース管理にコミットする必要がありますか?

Question

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

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

score 74 · Accepted Answer

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

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

おそらくもっと役立つ質問は、どのファイルを除外する必要があるかということです。VS2008プロジェクトの.gitignoreファイルの内容は次のとおりです。

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

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

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

ipch/
*.sdf
*.opensdf

score 59 · Accepted Answer

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

score 20 · Accepted Answer

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

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

score 13 · Accepted Answer

必ず持っているはずです。他の人が言及した理由に加えて、プロジェクト全体のワンステップビルドを可能にする必要があります。

score 8 · Accepted Answer

はい、コミットする必要があるのは次のとおりです。

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

コミットしてはいけないことは次のとおりです。

ソリューションユーザーオプション (.suo) ファイル、
生成されたファイルをビルドする (例: ビルドスクリプトを使用) [編集:] - 必要なすべてのビルドスクリプトとツールがバージョン管理下で利用可能な場合のみ (ビルドが cvs 履歴で本物であることを確認するため)

その他の自動生成ファイルについては、別スレッドがあります。

score 8 · Accepted Answer

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

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

さらに、プラグインを使用して、さまざまなチェックインポリシーをサポートします。これにより、一般的に、ユーザーが欠陥のあるコードや非準拠のコードをリポジトリに送信することが防止されます。

score 5 · Accepted Answer

はい、ソース管理の一部である必要があります。アプリケーションからプロジェクトを追加/削除するたびに、.sln が更新されるため、ソース管理下に置くことをお勧めします。これにより、アプリケーションコードを 2 バージョン前に引き出して、直接ビルドを実行できます (必要な場合)。

score 4 · Accepted Answer

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

score 4 · Accepted Answer

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

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

score 2 · Accepted Answer

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

score 2 · Accepted Answer

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

score 1 · Accepted Answer

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

score 1 · Accepted Answer

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

score 1 · Accepted Answer

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

score 0 · Accepted Answer

0

.slns は、 tfs で問題が発生していない唯一のものです!

于 2009-06-23T16:53:45.740 に答える

visual-studio - .sln をソース管理にコミットする必要がありますか?

15 に答える 15

Related

Reference