Revising GAC Installationen

Question

Dieser geht Runde um Runde ich weiß, aber ich kann nicht scheinen, eine befriedigende Antwort zu finden.

Sollten Baugruppen in den GAC gehen? Diese Fragen: when-and-when-not-to-install-into-the-gac und What are the advantages and disadvantages of using the GAC, Adresse genau das, aber die Antworten sind sehr viel "es wird empfohlen, dass ..." oder "Sie sollten nur ...". Warum???

Viele der GAC Naysays Blogs scheinen vor 5/6 Jahren zu datieren, als der Stern von .Net anfing zu steigen. Sind wir jetzt noch da? Sicherlich ist DLL-Hell Vergangenheit, da die GAC Seite an Seite die Installation verschiedener Versionen der "gleichen" Baugruppe unterstützt.

Lassen Sie mich meine Bedenken konkretisieren. Wir haben eine wachsende Anzahl von Web-Apps (bisher 5). Dies sind im Wesentlichen Erweiterungen für eine Anwendung eines Drittanbieters über API-Aufrufe und Datenbankerweiterungen. Offensichtlich teilen alle diese Apps viel Code gemeinsam und wir entwickeln einen neuen Satz von gemeinsamen Bibliotheken, um unsere Qualität, Wartbarkeit usw. zu verbessern.

Sicher möchte ich diese gemeinsame Funktionalität einmal installiert und geteilt. Alle Argumente, einen Wartungs-Alptraum zu eröffnen, scheinen auf einer Welt schlechter Disziplin zu beruhen. Wenn Sie den ABI brechen, reicht es aus, die AssemblyVersion zu stoßen, um Ihre bestehenden Apps funktionsfähig zu halten.

Ist der GAC wirklich eine Honigfalle für die Ahnungslosen? Bin ich naiv? Werde ich unnötig hart, wenn ich Argumente, die den Verlust von "XCopy" zitieren, als faule Jammern installiere? Oder wird es ein bisschen "religiös" und ich sollte einfach mit dem gehen, was richtig erscheint?

Danke, dass Sie mir geholfen haben, das Licht zu sehen.

Dan

Answer 1

Ich persönlich habe niemals Baugruppen direkt im GAC installiert (außer als rein akademische Übung). Ich habe das Argument schon mal gehört, dass man eine Assembly von einem zentralen Ort aus benutzt, auf den man von mehreren Anwendungen aus zugreift, und obwohl das persönlich irgendwie attraktiv erscheint, ist es meine Zeit nicht wert. Computer kommen heutzutage mit 320 GB Festplattenspeicher ... meine schäbige 160K-Baugruppe wird daran nichts ändern, selbst wenn sie 5 mal kopiert wird. (Natürlich könnten einige das "Problem der Gemeingüter" streiten ... Sie wissen: "Wenn jeder Entwickler so denkt ....", aber ich schweife ab). Der Hauptgrund, warum ich dies nicht tue, ist, weil eine bestimmte Anwendung sich auf die Assembly in einer Weise verlassen kann, während eine andere sich auf eine andere Weise darauf verlassen kann. In einer idealen Welt sollten Updates für diese Assembly die Anwendungen, die sich darauf beziehen, niemals beeinflussen, in der Realität jedoch oft. Wenn ich ein Problem mit einer Assembly behebe, weil eine bestimmte Anwendung Probleme damit hat, beeinflusse ich unwissentlich die anderen Anwendungen, die auf diese bestimmte Assembly angewiesen sind. Auf der anderen Seite könnten einige argumentieren, dass diese Art von Situation uns zu besseren Programmierern macht und unsere GAC-Shared-Baugruppe kugelsicherer macht. Das ist großartig, aber mein Job als Programmierer ist nicht in erster Linie, mich selbst zu einem besseren Programmierer zu machen, sondern um Programme zu schreiben, die funktionieren, und so werde ich ein besserer Programmierer werden.

Also, was ist meine Stimme? Halten Sie sich von der GAC fern. Lassen Sie jede Anwendung auf die Version der Assembly angewiesen sein, auf die sie basieren.Ein Fehler, der in dieser Assembly von einer Anwendung angezeigt wird, wird möglicherweise nie in den anderen Anwendungen angezeigt, da sie die Assembly unterschiedlich verwenden. Lassen Sie sie also unverändert, und Sie müssen nicht jedes Mal 5 unterschiedliche Anwendungen regression testen .

Answer 2

Ich verwende folgende schwache Strategie.
Verwenden Sie GAC - wenn verschiedene Programme gemeinsame Assembly + Versionierung verwenden.
Verwenden Sie nicht GAC - immer.

Kommentare sind willkommen.