Sollten Sie den Ordner bin nicht als vorübergehend behandeln?

Question

Ich habe mir selbst und anderen immer beigebracht, den bin-Ordner als vorübergehend zu betrachten.

Das sollten Sie in der Lage sein, es zu löschen, und das nächste Mal, wenn Sie es neu erstellen, wird es neu erstellt und alle Referenzen werden problemlos kopiert und Ihre Eier nicht in einen Korb gelegt. Oder legen Sie in diesem Fall nicht alle benötigten DLLs direkt in den Ordner "bin". Habe sie woanders und referenziere sie einfach.

Ich habe Leute gesehen, die heruntergefallen sind, als sie dlls direkt in den bin-Ordner gelegt haben und dort auf sie verwiesen haben. Also versuche ich dies zu vermeiden und setze alle meine benötigten DLLs in einen Ordner namens Refs und füge Referenzen zu den DLLs hinzu. Zur Kompilierzeit werden sie trotzdem in den bin-Ordner kopiert.

Bin ich verrückt? Ist das zu vorsichtig? gesunder Menschenverstand?

Was ist die beste Vorgehensweise in diesem Szenario?

Cheers,

- Lee

UPDATE: Es stellte sich heraus i nicht verrückt bin

Prost Jungs, Sie haben in einigen Punkten nahm ich vergaß zu erwähnen.

Hauptsächlich:

• Nicht

Answer 1

Das ist richtig, Sie nicht wollen referenzierte DLLs in den Ordner bin setzen.Wenn Sie die Versionskontrolle verwenden, sollten bin- und obj-Ordner immer vollständig ausgeschlossen werden.

Alle referenzierten DLLs sollten unter Versionskontrolle enthalten sein, vorzugsweise in einem separaten Unterverzeichnis unter trunk Ihres Projekts, so dass jeder Benutzer alle notwendigen Quellen und Referenzen für jede saubere Neuerstellung hat. bin Ordner muss leicht von Grund auf neu erstellt werden.

Das ist etwas, das glaube ich die meisten Menschen werden erwarten beim Auschecken Ihrer Quelle.

Wir schließen auch eine _READ_ME.txt Datei im Root des Projekts, die besagt, zusätzliche Informationen über Werkzeuge und Material benötigt, um Batch-bauen das Projekt (nant, perl, etc.), so kann es einige Unterschiede von Zeit zu Zeit, aber niemals Überraschungen dieser Art.

Answer 2

Nein, das macht durchaus Sinn, den Ordner ist in der Quellcodeverwaltung überprüft und ist eine Praxis, die ich mich auf persönliche Projekte umzusetzen. Alles unter dem bin-Ordner sollte als Eigenschaft der Msbuild-/Visual Studio-Umgebung behandelt werden.

Während beide sehr sorgfältig darauf achten, nur die ihnen bekannten Ausgaben zu löschen, ist es für den Benutzer möglich, nicht vollständig zu verstehen, was die Build-Ausgabe ist und über eine Build-Ausgabe kopieren und folglich während eines "Clean" -Stils löschen Betrieb. Es ist auch möglich, dass andere Tools hier aggressiver arbeiten, um DLLs zu bereinigen. Ich neige dazu, das bin-Verzeichnis von Zeit zu Zeit zu durchsuchen, wenn ich glaube, dass der Build-Prozess nach veralteten Daten aussieht.

Wenn Sie den Speicherort eines Verweises angeben, können Sie Referenzen für eine Sammlung von Projekten in einer Lösung aktualisieren. Für mich ist es ein sehr natürliches Konstrukt.

Answer 3

Ich habe keine Ahnung, ob du verrückt bist, aber wir haben die gleichen Praktiken an dem letzten Ort, an dem ich gearbeitet habe, übernommen und ich habe sie zu meiner eigenen Arbeit getragen. Die Ordner/bin und/obj liegen außerhalb der Versionskontrolle und etwas, das ich nie anfasse. Sie existieren grundsätzlich nicht, soweit es mich bei der Entwicklung betrifft. Alle enthaltenen DLLs sitzen in einem anderen Ordner und sind referenziert.

Answer 4

Ich denke, der bin-Ordner als vorübergehend, es ist ein Ort für die vollständige funktionierende kompilierte Anwendung zu gehen.

Wir platzieren alle externen Assemblies in einem Verzeichnis namens Assemblies. Viele andere benutzen ein Verzeichnis namens lib. Dies trennt die Idee von etwas, das benötigt wird, um die Anwendung von der kompilierten Anwendung selbst zu kompilieren.