ソリューションをコンパイルするには、次のタイプのファイルが書き込み可能である必要があるようです。.exe .dll .pdb (デバッグの場合) .resource (?) .xml (少なくともシステムによって生成されたもの。すべてが XML ドキュメント ファイルであるかどうかはわかりません)
それらがチェックインされていて、それらをチェックアウトした人だけがコンパイラによって上書きできる場合、それらをソースセーフにチェックインし、実行するたびにコンパイラによって試みられるそれらを変更するためにチェックアウトを要求すると、他のデバッグおよび実行する開発者の能力。
ベストプラクティスは何ですか? VSS がすべてを自動的に追加するようです。
通常、生成されたファイルを 1 回生成し、そこからファイルを「カットアンドラン」する (つまり、再生成しない) 場合を除き、生成されたファイルをチェックインする必要はありません。これは、シングル チェックアウト ロックを使用する VSS などのバージョン管理システムに特に当てはまります。
生成されたファイルをバージョン管理する場合は、ソリューション/プロジェクトの場所でそれらをバージョン管理しないことをお勧めしますが、それらを別の場所にコピーしてそこにチェックインする別のプロセスを用意することをお勧めします。生成されたファイルを sln/proj 内でバージョン管理すると、それらをチェックアウトして戻すために人々と戦う悪夢に見舞われることになります。
チェックアウト時に排他ロックを行わないように VSS を設定できると思いますが、一般的には、生成されたファイルをチェックインしないようにします。生成されたファイルの以前のバージョンに戻る必要がある場合は、「ソース」ファイルの適切なバージョン/タグをチェックアウトし、そこから他のファイルを再生成するようにシステムを取得する必要があります。
一般に、ビルド プロセスの一部として作成されるファイルは、バージョン コントロールにチェックインされません。
ただし、テストで見つかった問題レポート/バグに対処する必要がある場合に備えて、これらのファイルのすべてまたは一部をアーカイブすることをお勧めします (おそらく特定のマイルストーンで、特に開発組織の外にリリースする場合)。利用者。
ソース アーティファクトと同じデポで (または同じバージョン管理ソフトウェアを使用して) アーカイブを実行するかどうかは、別の決定事項です。多くの場合、この種のアーカイブは実際にはバージョン管理システムではありませんが、特定の命名規則に従うディレクトリを持つネットワーク共有である可能性があるため、これらのアーティファクトをソースの特定のリビジョンに一致させることができます。これらのアイテムの有効期間をどのように管理するか (および有効期間をどうするか) は、特定の組織のニーズとポリシーによって決定する必要がある別の問題です。
Visual Studio は、ソース セーフに追加する適切な項目を適切に選択します。新しいプロジェクトを設定するときは、プロジェクトのコンテキスト メニューまたはファイル メニューからコマンドを使用します。
よくある間違いは、VSS からフォルダーを追加することです。