Zu GAC oder nicht zu GAC?

Question

Ich habe eine Datenzugriffsschicht (DAL), die in ASP.NET 3.5 geschrieben ist und verwendet die Microsoft-Muster & Praktiken Bibliotheken (im Folgenden als P & P bezeichnet), um seinen Datenzugriff zu erreichen. Ich installierte P & P und es befindet sich in meinem GAC, also, logisch, meine DAL verweist es in der GAC. Daher werden die P & P-Bibliotheken nie in den Bin-Ordner meiner DAL gezogen.

Ich benutze dieses DAL-Projekt in mindestens fünf (mehr als das sogar, aber ich bin zu faul, um sie alle zu zählen) verschiedene Websites. Und das hat alles gut für mich funktioniert, weil ich der einzige Entwickler bin, der auf diesen Webseiten arbeitet.

Aber jetzt habe ich andere Entwickler, die auf einigen dieser Websites arbeiten werden.

Das Problem: wenn ein Entwickler das DAL-Projekt nach unten aus unserer Code-Repository zieht, wird es nicht für sie baut, wenn sie die P & P Bibliotheken nicht installiert haben.

Meine Frage: sollte ich die Entwickler erwarten, dass die P & P Bibliotheken installieren, oder sollte ich sie einfach in den Papierkorb-Ordner entleeren und mit ihr geschehen?

Ich weiß, dass es am einfachsten ist, sie in den Ordner "bin" zu legen, aber ich war noch nie ein großer Fan des bin-Ordners, wenn ich sie stattdessen im GAC referenzieren kann.

Answer 1

Dies ist weitgehend stilistische Präferenz für Ihre spezielle Arbeitsgruppe. Ich bevorzuge das Paketieren von Websites auf die gleiche Weise, wie ich Clientanwendungen paketiere: mit allen erforderlichen Binärdateien, die nicht im .NET-Framework enthalten sind, mit der Annahme, dass auf keiner Maschine, auf die sie kopiert oder installiert wird, etwas zu finden ist der GAC. Mein Team bei der Arbeit hält unsere Drittanbieter-Assemblies als Binärdateien in die Quellcodeverwaltung eingecheckt und als Referenzabhängigkeiten markiert, sodass alle auf derselben Seite mit den gleichen Binärdateien arbeiten und wir uns nie Gedanken über Installationsunterschiede zwischen den Maschinen der Entwickler machen müssen.

Der GAC kann ein praktischer Platz sparender Mechanismus sein, aber ich bevorzuge die Konsistenz zwischen Entwicklerumgebungen, die durch "Inlining" der Dateien bereitgestellt werden.

Answer 2

Nachdem ich in der Vergangenheit an Projekten mit GAC-Abhängigkeiten gearbeitet habe, war es immer verwirrend und schwierig, Projekte korrekt zu konfigurieren, was dazu führte, dass alle Arten von Verzögerungen gerade erst begannen. Es kann zu einem größeren Problem werden, wenn Sie neue Versionen der DAL entwickeln. Das mag gut geklappt haben, als du alleine warst, aber ich würde jetzt wirklich den bin dump in Betracht ziehen, wenn du ein größeres Team hast.

Answer 3

Ich denke, Sie sollten ihnen die Möglichkeit geben, beides zu tun.

Für die Faulen bieten die pp DLLs sowie eine signierte DAL DLL. Für die erfahreneren erlauben sie, es zu bauen, stellen Sie einfach sicher, dass sie wissen, dass sie P & P benötigen, und alle Änderungen an der DLL müssen gacced werden.

Ich bevorzuge immer Shared Libraries, die speziell auf der Serverseite gac'ed werden. Für Kunden packe ich generell gerne in bin.