Welche ASP.NET MVC-Projektdateien sollten in einem Repository aufbewahrt werden?

Question

Hintergrund: Ich und meine Mitarbeiter arbeiten auf asp.net mvc Projekt ... wir haben einen Computer, der als Server arbeitet, wo das Projekt gespeichert wird ... jeder von uns hat eine Kopie des Projekts und Wir haben Schildkrötencvs aufgestellt.

Fragen: , wenn Sie etwas begehen wollen, was genau Dateien begehe Sie .. asp.net Berichte viele DLL-Dateien, csproj Dateien, cs und SLN-Dateien, die vom Server der, anders zu sein scheinen.

Vielleicht ist meine Frage nicht die richtige, die ich stellen sollte, daher würde ich mich über einige Einsichten freuen, wie der beste Ansatz für die Arbeit in Gruppen ist.

Answer 1

Die Grund csproj Datei verpflichtet werden sollen, wenn Sie die Dinge aus dem Projekt hinzuzufügen oder zu entfernen, um sicherzustellen, dass das Projekt alle richtigen Dateien. Die Lösung (SLN) ist aus dem gleichen Grund eine gute Sache, obwohl ich es auch ohne gesehen habe. Sie möchten natürlich auch alle CS-Dateien, da sie den Schwerpunkt der Dinge sind.

DLL-Dateien sollten nur festgeschrieben werden, wenn es sich um externe Referenzen handelt - interne DLLs für Ihr Projekt können ignoriert werden, da sie von jedem Computer nacheinander erstellt werden. Sie wollen auch .user Dateien als unnötig vermeiden. Ignoriere die Ordner 'bin' und 'obj' für jedes Verzeichnis, auch wenn es zu Commits kommt.

Answer 2

Sie sollten wirklich nichts einchecken, das das Projekt selbst erzeugen kann. Es ist also nicht nötig, den Ordner "bin" oder "obj" oder etwas Ähnliches einzuchecken. Sie sollten auch alle Benutzervorgaben ignorieren.

Dazu gehören dlls, es sei denn, sie Dritten dlls sind, dann möchten Sie sie in überprüfen, um sicherzustellen, jeder arbeitet gegen die gleiche Version und auf diese Weise müssen Sie Änderungswege Referenz nicht zu halten.

Answer 3

Wir behalten alles außer den BIN/OBJ Ordnern in SVN. Wir haben alle Bibliotheken von Drittanbietern in einem separaten Ordner, auf den sie referenziert werden.

Güte,

Dan

Answer 4

Ich arbeite nicht in asp.net, also werde ich generisch antworten. Wir haben ein Subversion-Code-Repository für unser Versionssystem, cvs funktioniert auch gut. Entwickler rufen den gesamten aktualisierten Code aus dem Repository ab, erledigen die Arbeit, stellen sicher, dass sie ordnungsgemäß funktioniert, führen einen anderen Get aus, kompilieren erneut, testen und dann quittieren Code-Änderungen in das Repository. In regelmäßigen Abständen können Sie ein Tool verwenden oder die Anwendung manuell aus dem Repository erstellen und auf einem Testserver bereitstellen. Kein kompilierter Code sollte im Repository abgelegt werden.

-Jay

Answer 5

Wir verwenden die folgende Projektstruktur in SVN (aber das gilt für CVS als auch).

+ tags 
+ branches 
> trunk 
    + build (build scripts) 
    + lib (external libraries) 
    > src (source code)  
    >> Organization.App (solution name) 
    >> Organization.App.Core (code library) 
     + Config 
     > Domain 
      > Model 
      > Persistence 
      > Queries 
      > Services 
     > Persistence 
     > Services 
    >> Organization.App.Web (mvc web app) 
     > Assets 
      + Images 
      + Scripts 
      + Stylesheets 
     + Controllers 
     + Views 
     + ViewModels 

Wir setzen alle Abhängigkeiten von Drittanbietern in den lib-Ordner. Einschließlich MVC, die bin bereitgestellt werden kann. See this article by Phil Haack. Wenn also ein neuer Entwickler online geht, muss er den Kofferraum auschecken, und sie sollten alles haben, was sie brauchen, um loszulegen. Die Verwendung eines CI-Servers ist ein Kinderspiel, da alle Projektabhängigkeiten vom lib-Ordner gekapselt sind und alle Visual Studio-Projekte auf diese DLLs in diesem lib-Ordner verweisen.

Macht das Sinn?

Vergessen Sie nicht den Hauptordner und den Webordner. So strukturieren wir unsere Projekte innerhalb der Lösung. Aber das ist ein whole other conversation. :)

Answer 6

Wenn Sie ein Datenbankänderungs-Verwaltungstool verwenden, z. B. Tarantino, dann sollten Sie auch SQL-Änderungsskripts einchecken und/oder Skripte füllen. Wir haben einen Ordner in unserer "Core" -Lösung, wo wir diese aufbewahren, also "Core/Database/Updates". Wir verwenden SQL Compare, um Änderungen in unserer Datenbank zu finden, dann checken wir diese SQL-Änderungsskripte ein, damit andere Entwickler sie nur lokal ausführen können. Wir haben eine Task-Einrichtung eingerichtet, um Tarantino aufzurufen, die anderen Build-Umgebungen (Dev, QA) zu synchronisieren und neue Change-Skripte auszuführen.