回答:
一般的なルールとして、ソース管理はソースのみに使用するのが最適であり、生成されたファイルはソースではありません。
例外があります。場合によっては（Visual Studioを使用して）ミニダンプを読み取るために.pdbファイルを保持することもできます。生成されたファイルを必ずしも正確に再作成できないように、ツールチェーンを複製できない場合があります。これらのケースでは、VCSのすべての変更ではなく、リリースされたソフトウェアに対してこれを行うことに主に関心があり、いずれの場合もバージョン管理されたフォルダーに簡単に配置できます。（とにかく、これらは通常バイナリファイルであり、あるバージョンから別のバージョンへの包括的な変更はなく、VCSに含まれていることからそれほど利益を得ることはありません。）
簡単な答え？いいえ、それをしないでください！そうしない多くの理由を考えることはできませんが、あなたがしたいと思う理由はありません。
dllをチェックインできると思うのは、すべての開発者がビルドするためにインストールしたとは思わないサードパーティライブラリの場合だけです。それでも、binフォルダーにはありません。
つまり、私は各展開パッケージをソース管理に入れる必要がある会社で働いていましたが、それは私たちがクライアントに与えたさまざまなビルドを追跡し、必要に応じて簡単にロールバックできるようにするためでした。
binフォルダーをTFSにチェックインしません。お気づきかもしれませんが、そうすれば、開発者がソリューションを作成するたびに、binフォルダーをチェックアウトすることになります。良くない。ただし、プロジェクトがコンパイルして実行するために必要なライブラリがあります。私たちのルールは、プロジェクトをソース管理から開くことができ、コンパイルして実行する必要があるということです。そのため、プロジェクトが参照する必要があるDLLの「BinRef」フォルダーを作成し、BinRefフォルダーにコピーへのプロジェクト参照を作成します。BinRefフォルダーが TFSにチェックインされます。
このアプローチのもう1つの利点は、BinRefが常にWebプロジェクトのルートレベルにあることです。私のプロジェクトが住んでいてC:\Projects\Marcie\SomeProjectCategory\ProjectA、そこにあるDLLへの参照を作成するC:\DLLsThatILikeと、参照は最終的に次のようになります
\..\..\..\NiceThing.dll
。プロジェクトファイルを保存することもできます。C:\ProjectAつまり、NiceThingへのプロジェクト参照がマシン上で爆発します。うまくいけば、人々はこのように参照をしていませんが、私はそれが起こるのを見ました。
変更要求プロセスの一環として、binディレクトリの内容をチェックインします。読み取り専用の問題を回避するために、コンテンツを別のフォルダーにコピーし、そこからチェックインします。当社の企業ポリシーでは、本番環境に移行するすべてのバイナリはソースとは別にチェックインする必要があります。これは最善の解決策ではありませんが、機能し、実稼働中の正確なファイルを提供します。
テキスト以外のファイルをソース管理にチェックインするのをためらいます。特に、開発者が生成する必要があるもの。また、画像やPDFなどの他のバイナリファイルを圧縮して、タグ/リリースごとに別の場所に保存することも好きです。
いいえ。ただし、社内のプロジェクト管理ツールは自動的に実行されるため、私には困ります。
私の解決策は、リリース内のすべてのファイルを書き込み可能としてマークし、TFSがファイルを無視するように不満を言うと、ビルドが失敗するという問題が発生しないようにすることです。