Kurze Frage zu TFS - Checkt ihr Bin / Debug-Ordner in TFS ein? (Wenn ja, warum?) Da der Inhalt dieser Ordner dynamisch generiert wird, ist es besser, sie wegzulassen, damit der Programmierer nicht auf schreibgeschützte Probleme stößt.
Antworten:
In der Regel wird die Quellcodeverwaltung nur für die Quelle verwendet, und generierte Dateien sind keine Quelldateien.
Es gibt Ausnahmen. Manchmal (mit Visual Studio) möchten Sie möglicherweise die PDF-Datei zum Lesen von Minidumps behalten. Manchmal können Sie eine Toolchain nicht duplizieren, sodass Sie generierte Dateien nicht unbedingt genau neu erstellen können. In diesen Fällen sind Sie in erster Linie daran interessiert, dies für freigegebene Software und nicht für jede VCS-Änderung zu tun. In jedem Fall können sich diese problemlos in versionierten Ordnern befinden. (Dies sind ohnehin normalerweise Binärdateien, die von einer Version zur anderen keine nachvollziehbaren Änderungen aufweisen und nicht allzu sehr von der Verwendung in einem VCS profitieren.)
Einfache Antwort? Tu es nicht! Ich kann mir nicht viele Gründe vorstellen, es nicht zu tun, aber keinen Grund, warum Sie es wollen würden.
Ich kann mir nur vorstellen, dass Sie eine DLL einchecken würden, wenn sie aus einer Drittanbieter-Bibliothek stammt, von der Sie nicht erwarten, dass jeder Entwickler sie installiert hat. Trotzdem befindet sich das nicht im Ordner bin.
Davon abgesehen habe ich bei einem Unternehmen gearbeitet, bei dem jedes Bereitstellungspaket in die Quellcodeverwaltung übernommen werden musste, aber so konnten wir die verschiedenen Builds verfolgen, die wir unserem Kunden gegeben haben, und bei Bedarf problemlos ein Rollback durchführen.
Wir checken den bin-Ordner nicht in TFS ein. Wie Sie wahrscheinlich bemerkt haben, checkt jeder Entwickler jedes Mal, wenn er die Lösung erstellt, den Ordner bin aus. Nicht gut. Es gibt jedoch Bibliotheken, die das Projekt zum Kompilieren und Ausführen benötigt. Unsere Regel lautet, dass jedes Projekt über die Quellcodeverwaltung geöffnet werden kann und kompiliert und ausgeführt werden sollte. Wir erstellen also einen "BinRef" -Ordner für alle DLLs, auf die das Projekt verweisen muss, und erstellen die Projektreferenzen für die Kopie im BinRef-Ordner. Der BinRef-Ordner wird in TFS eingecheckt.
Der andere Vorteil dieses Ansatzes besteht darin, dass sich BinRef immer auf der Stammebene des Webprojekts befindet. Wenn mein Projekt darin lebt C:\Projects\Marcie\SomeProjectCategory\ProjectAund ich einen Verweis auf eine DLL erstelle, in der C:\DLLsThatILikesich der Verweis befindet, sieht der Verweis am Ende ungefähr so aus
\..\..\..\NiceThing.dll
. Sie können Ihre Projektdateien behalten, C:\ProjectAwas bedeutet, dass der Projektverweis auf NiceThing auf Ihrem Computer explodiert. Hoffentlich machen die Leute keine Referenzen auf diese Weise, aber ich habe gesehen, dass es passiert ist.
Wir checken den Inhalt der bin-Verzeichnisse im Rahmen unseres Änderungsanforderungsprozesses ein. Um die schreibgeschützten Probleme zu vermeiden, kopieren wir den Inhalt in einen separaten Ordner und checken ihn von dort aus ein. Unsere Unternehmensrichtlinie verlangt, dass alle Binärdateien, die in die Produktion gehen, getrennt von der Quelle eingecheckt werden. Es ist nicht die beste Lösung, aber es funktioniert und es gibt uns die genauen Dateien, die in Produktion sind.
Ich zögere, Nicht-Textdateien in die Quellcodeverwaltung einzuchecken. Insbesondere solche, die vom Entwickler generiert werden sollten. Ich möchte auch andere Binärdateien wie Bilder und PDFs komprimieren und für jedes Tag / jede Veröffentlichung an anderer Stelle speichern.
Nein, aber unser internes Projektsteuerungs-Tool funktioniert automatisch, was mich nervt.
Meine Lösung besteht darin, alle Dateien in Release und Debug als beschreibbar zu markieren. Wenn sich TFS beschwert, fordere ich es auf, die Dateien zu ignorieren, damit ich nie ein Problem mit einem fehlgeschlagenen Build habe.
Ich vermeide es, sie in die Quellcodeverwaltung einzugeben. Es handelt sich um redundante Informationen. Die Binärdateien können anhand des Quellcodes in dieser Version erstellt werden. Außerdem ist der Quellcode immer auf dem neuesten Stand, die Builds sind möglicherweise nicht festgeschrieben.
Ich speichere einige generierte Binärdateien, wie z. B. .NET-Interops aus einem anderen Projekt. Wenn ich also ein Projekt A habe, das ein COM-Objekt erstellt, und Sie dieses COM-Objekt dann in einem sehr lose verwandten Projekt B verwenden, das es über .NET-Interop verwendet, checke ich das aus Projekt A generierte Interop in Projekt B ein Keine gute Idee, aber es muss irgendwohin gehen, da AFAIK Visual Studio während des Builds nicht automatisch das Interop für Sie erstellt.
Meiner Meinung nach ist es einer der häufigsten Fehler, keine Binärdateien in der Quellcodeverwaltung zu speichern. Sie sollten zusammen mit den Quellen gespeichert, versioniert, baselined / etikettiert werden und auch Tools erstellen. Kombinieren Sie sich mit der Erstellung nicht rückverfolgbarer Software ...