Wie soll ich mich reference assemblies von einer anderen Lösung?
Habe ich zwei Szenarien:
-
Es ist ein Framework-Projekt für das Unternehmen, und für alle Projekte, die wir gehen, um mit diesem framework.
-
Gibt es eine eigene Framework-Projekt ist spezifisch für einen client und nur einige Leute in der Firma jemals brauchen werden, um mit dieser DLL.
Beide frameworks gespeichert sind, in getrennte Lösungen auf TFS.
Wie soll man anhand der Referenzen für andere Projekte? Sollte ich die beiden Baugruppen auf GAC oder so? Sollte ich kopieren Sie die Ausgabe-Baugruppe manuell? Was ist zu empfehlen, warum und wie verwende ich es?
- Dies mag zwar nicht wertvoll sein, um Ihre situation, wenn Sie wurden mit subversion, svn:externals gewesen wäre, eine ziemlich einfache Lösung für diese situation.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Custom Rahmen
Kopieren Sie die Ausgabe-Baugruppe manuell in das custom-Projekt, es sei denn, Sie können es-Quelle direkt in die Lösung.
Gemeinsamen Rahmen
Ich würde nuget statt GAC jeder Zeit, seit Sie loszuwerden, keine versionsprobleme oder zu erstellen, ein separates Installationspaket für den Rahmen (da du GAC)
Es ist ganz einfach erstellen Sie ein eigenes nuget-server. Erstellen Sie einfach ein neues MVC3 Projekt, und installieren Sie eine der nuget-server-Paket: http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds
Fügen Sie die referenzierte assembly in einer Bibliothek Ordner in den anderen Projekten und manuell aktualisieren.
Erwägen Sie die Verwendung Ihrer eigenen NuGet feed, wenn Häufig aktualisiert.
Klingt für mich ein klassisches Projekt-Referenz vs binären Referenz Entscheidungsfindung. Lassen Sie die GAC aus diesem.
In Topologien, die ähnelt Ihrer Anforderung verwenden wir so etwas wie dieses:
Sollten Sie teilen, Baugruppen durch die Installation in den global assembly cache nur, wenn Sie müssen. Als Allgemeine Richtlinie, halten Sie assemblyabhängigkeiten privat, und suchen Sie assemblies im Verzeichnis Anwendung wenn die Freigabe einer assembly wird ausdrücklich gefordert. Darüber hinaus ist es nicht notwendig, installieren Sie die Assemblys in dem globalen Assemblycache zugänglich zu machen, die COM-interop oder nicht verwalteten code
Ich würde die erste framework-ddl-s in den GAC, weil der oben genannten.
Ich würde den zweiten Rahmen in einen gestalteten Ordner unter Ihrem TFS-Aufruf durch die Instanz "Bibliothek", wo Sie fügen Sie einen Verweis aus (Alle Teams müssen die gleiche Ordner-Struktur zu vermeiden, fehlt Referenzen)
Also #2 die benutzerdefinierte Framework-Projekt ist das gleiche wie #1, aber angepasst für einen bestimmten client?
Würde es Sinn machen die custom Framework-Quellcode ein Zweig der normalen Framework-Quellcode, anstatt halten Sie es als eine tatsächliche separate Lösung? Ich nehme an, dass es davon abhängen würde, wie groß die Unterschiede sind.
Wie ich es sehe, ist der Vorteil, dass es eine Niederlassung ist, dass Sie sollten in der Lage sein, um leichter änderungen zwischen den beiden Zweigen. Stellt Euch vor, ein Bugfix oder ein neues feature gemacht, die in #1 und auch angewendet werden muss, um #2; TFS in der Lage sein sollten, um dies zu erleichtern, vorausgesetzt, dass TFS ist sich bewusst, dass #2 ist nur ein Zweig der #1.
Jedenfalls, um zum Punkt deiner Frage, mein Gedanke ist dann, dass andere Projekte sollten Referenz die Ausgabe-Baugruppen, die aus diesen Projekten.
Ich würde kopieren der Framework-Assemblys in einem Ordner unter dem Projektmappenordner von deinen anderen Projekten. Ich in der Regel rufen Sie mir "Abhängigkeiten", aber es spielt wirklich keine Rolle. Haben Ihre Projekte fügen Sie einen Verweis auf diese assembly-Dateien. Ich gehe davon aus, dass Ihre benutzerdefinierte Framework-Assemblys werden, die den gleichen Namen haben wie die normale Framework-Assemblys, so können Sie hoffentlich einfach austauschen dieser Dateien als erforderlich (oder erstellen Sie separate Zweige der Sie Ihre Projekte, verwenden Sie die benutzerdefinierte Framework).
Ich würde entmutigen, setzen Sie die Assemblys im GAC, weil es einfach ist die Reise selbst, während der Entwicklung, wenn Sie vergessen haben, deinstallieren Sie eine ältere version der assembly aus dem GAC.