我一直教導自己和其他人將bin文件夾視爲瞬態文件。不應該將bin文件夾視爲瞬態文件嗎？
這就是你應該能夠刪除它，下次你重建它會得到重新創建和任何引用複製到它沒有任何麻煩而不是把你的雞蛋都放在一個籃子裏。或者在這種情況下，不要將所有必需的dll直接放到bin文件夾中。有他們在其他地方，只是參考他們。
我見過有人在將dll直接放入bin文件夾並在那裏引用時掉下來。所以我儘量避免這種情況，並將所有我需要的dll放在名爲Refs的文件夾中，並在其中添加對dll的引用。在編譯時，它們將被複制到bin文件夾中。
我瘋了嗎？這是否過於謹慎？常識？
這種情況下的最佳做法是什麼？
乾杯，
- 李
更新：原來我是不是瘋了你拿起一些問題上我忘了提
乾杯傢伙。
主要是：
沒錯，你不要想把參考dll放在bin文件夾中。如果您使用版本控制，則應始終完全排除bin和obj文件夾。
所有引用的dll都應該包含在版本控制之下，最好在項目的trunk下的單獨子目錄中，以便每個人都有每個乾淨重建所需的所有源和引用。 bin文件夾必須輕鬆從頭開始重新創建。
這是我相信大多數人會檢查您的來源期望。
我們還包括一個_READ_ME.txt文件中項目的根，註明需要批量生成項目（nant，perl等）工具和東西的附加信息，所以有可能是從時間到一些特定的差異時間，但從來沒有這種驚喜。
'bin和obj文件夾應始終完全排除在外+1'。 – 2009-10-12 16:58:14
沒有這使得完整意義上的，是我自己在個人項目實施的做法。 bin文件夾下的任何內容都應該視爲msbuild/Visual Studio環境的屬性。
雖然他們都非常小心只刪除他們知道的輸出，但用戶可能無法完全理解構建輸出是什麼並複製到構建輸出上，並因此在「Clean」樣式期間將其刪除操作。在清理DLL的時候，其他工具也可能會更積極。如果我認爲構建過程正在查看陳舊的數據，我自己往往會不時刻造bin目錄。
此外，有一個ref的位置給你一個地方來更新解決方案中的項目集合的引用。對我來說這是一個非常自然的構造。
我不知道你是否瘋了，但我們在最後的工作地點遵循了相同的做法，並且把它們帶到了我自己的工作中。/bin和/ obj文件夾在版本控制之外，並且我從來沒有碰過。就發展過程而言，它們基本上不存在。所有包含的DLL坐在另一個文件夾中並被引用。
我認爲bin文件夾是暫時的，它是完整工作編譯應用程序去的地方。
我們將所有外部裝配放在名爲裝配的目錄中。許多其他人使用一個名爲lib的目錄。這將編譯應用程序本身所需的某些東西分離出來。
我覺得同樣的方式，總是把我的DLL直接放在項目文件夾中。 Visual Studio使用項目根作爲刷新路徑，所以如果我更新我的DLL，引用不會中斷。 – 2009-10-12 16:16:19