Czy nie należy traktować folderu bin jako przejściowego?

Question

Zawsze nauczyłem siebie i innych, aby uważali folder bin za przejściowy.

To powinieneś być w stanie go usunąć, a następnym razem, gdy go odbudujesz, zostanie odtworzony, a wszelkie odniesienia zostaną skopiowane do niego bez żadnych kłopotów I nie umieszczania wszystkich jajek w jednym koszyku. Lub w tym przypadku nie umieszczaj wszystkich wymaganych dll bezpośrednio w folderze bin. Mają je gdzie indziej i po prostu odwołuj się do nich.

Widziałem, jak ludzie upadają, kiedy umieszczają biblioteki DLL bezpośrednio w folderze bin i tam je odsyłają. Tak więc staram się tego uniknąć i umieścić wszystkie moje wymagane biblioteki dll w folderze o nazwie Refs i dodać odniesienia do bibliotek DLL tam. W czasie kompilacji i tak zostaną one skopiowane do folderu bin.

Czy jestem szalony? Czy to jest zbyt ostrożne? zdrowy rozsądek?

Jaka jest najlepsza praktyka w tym scenariuszu?

Cheers,

- Lee

Aktualizacja: Okazuje się, że nie jestem szalony

Cheers faceci już podejmowany w niektórych punktach zapomniałem wspomnieć.

Głównie:

• Nie sprawdzając folder bin do kontroli źródła

Answer 1

Zgadza się, ty nie chcesz chcesz umieścić odniesienia bibliotek dll w folderze bin.Jeśli używasz kontroli wersji, foldery bin i obj powinny być zawsze całkowicie wykluczone.

Wszystkie referencyjne biblioteki dll powinny być zawarte w ramach kontroli wersji, najlepiej w oddzielnym podkatalogu pod projektem trunk, aby każdy miał wszystkie niezbędne źródła i referencje dla każdej czystej odbudowy. bin folder musi być łatwo odtworzony od podstaw.

Jest to coś, w co wierzę, że większość ludzi będzie oczekiwała oczekiwać podczas sprawdzania źródła.

Mamy także plik w katalogu głównym projektu _READ_ME.txt, podając dodatkowe informacje na temat narzędzi i innych rzeczy potrzebnych do partii-budowania projektu (nant, perl, etc.), więc mogą istnieć pewne specyficzne różnice od czasu do czas, ale nigdy nie zaskakuje tego rodzaju.

Answer 2

No to sprawia, że ​​kompletny sens i jest praktyką ja wdrożenia projektów osobistych. Wszystko, co znajduje się w folderze bin, powinno być traktowane jako własność środowiska msbuild/Visual Studio.

Podczas gdy obie starają się usunąć tylko te wyjścia, o których wiedzą, możliwe jest, że użytkownik nie będzie w pełni rozumiał, jakie są dane wyjściowe kompilacji i kopiuje dane wyjściowe kompilacji, w związku z czym powinien je usunąć podczas "czystego" stylu operacja. Możliwe jest również, że inne narzędzia będą bardziej agresywne w czyszczeniu bibliotek DLL. Sam staram się od czasu do czasu niszczyć katalog bin, jeśli myślę, że proces kompilacji szuka nieaktualnych danych.

Dodatkowo posiadanie lokalizacji referencyjnej zapewnia jedno miejsce do aktualizacji referencji dla kolekcji projektów w ramach rozwiązania. Dla mnie to bardzo naturalna konstrukcja.

Answer 3

Nie mam pojęcia, czy jesteś szalony, ale postępowaliśmy zgodnie z tymi samymi praktykami w ostatnim miejscu, w którym pracowałem, i przeniosłem je do mojej pracy. Foldery/bin i/obj są poza kontrolą wersji i czymś, czego nigdy nie dotykam. Zasadniczo nie istnieją one tak daleko, jak jestem zainteresowany podczas rozwoju. Wszystkie dołączone pliki DLL znajdują się w innym folderze i są przywoływane.

Answer 4

Uważam, że folder bin jest przejściowy, więc jest to miejsce, w którym można uruchomić pełną kompilowaną aplikację.

Umieszczamy wszelkie zewnętrzne Złożenia w katalogu o nazwie Złożenia. Wiele innych używa katalogu o nazwie lib. Oddziela to ideę czegoś, co jest potrzebne do kompilowania aplikacji z samej skompilowanej aplikacji.