Rivisitazione di installazioni GAC

Question

Questo va in giro e lo so ma non riesco a trovare una risposta soddisfacente.

Gli assembly devono essere inseriti nel GAC? Queste domande: when-and-when-not-to-install-into-the-gac e What are the advantages and disadvantages of using the GAC, si riferiscono esattamente a questo, ma le risposte sono molto "si raccomanda che ..." o "si dovrebbe solo ...". Perché???

Un sacco di blog Naysaying GAC sembrano risalire a 5/6 anni fa quando la stella di .Net stava iniziando la sua ascesa. Siamo ancora lì adesso? Sicuramente DLL-Hell è una cosa del passato con il GAC che supporta l'installazione affiancata di diverse versioni dello "stesso" assembly?

Lasciami incarnare le mie preoccupazioni. Abbiamo una suite crescente di app Web (5 finora). Queste sono, in sostanza, estensioni di un'applicazione di terze parti tramite chiamate API ed estensioni del database. Ovviamente, tutte queste app condividono una grande quantità di codice in comune e stiamo sviluppando una nuova serie di librerie condivise di base per migliorare la nostra qualità, manutenibilità, ecc.

Sicuramente voglio questa funzionalità condivisa installata una volta e condivisa. Tutti gli argomenti sull'apertura di un incubo di manutenzione sembrano basati su un mondo di scarsa disciplina. Se si interrompe l'ABI, è sufficiente superare la AssemblyVersion per mantenere attive le app esistenti.

Il GAC è davvero una trappola per il miele per gli ignari? Sono ingenuo? Sono inutilmente severo quando rigetto gli argomenti che citano la perdita dell'installazione di XCopy come lazy lanciando? O sta diventando un po '"Religioso" e dovrei semplicemente andare con quello che sembra giusto?

Grazie per avermi aiutato a vedere la luce.

Dan

Answer 1

Personalmente non ho mai installato alcun assembly direttamente nel GAC (tranne che come esercizio puramente accademico). Ho già sentito l'argomento sull'utilizzo di un assieme da una posizione centralizzata a cui si accede da diverse applicazioni, e mentre ciò sembra alquanto attraente, personalmente, non vale il mio tempo. I computer arrivano con 320 GB di spazio su disco rigido in questi giorni ... il mio misero assemblaggio 160K non intaccherà, anche se è stato copiato 5 volte. (Certo, alcuni potrebbero argomentare il "problema dei beni comuni" ... sai: "se ogni sviluppatore la pensava così ...", ma sto divagando). Il motivo principale per cui scelgo di non farlo è che una particolare applicazione potrebbe fare affidamento sull'assemblaggio in un modo, mentre un altro potrebbe fare affidamento su di esso in un altro modo. Mentre ci si trova in un mondo ideale, gli aggiornamenti di questo assembly non dovrebbero mai influire sulle applicazioni che si basano su di esso, in realtà, spesso lo fa. Se risolvo un problema con un assembly perché una particolare applicazione ha problemi con esso, sto influenzando involontariamente le altre applicazioni che si basano su quel particolare assembly. D'altra parte, alcuni potrebbero obiettare che questo tipo di situazione ci rende migliori programmatori e rende il nostro assembly GAC-Shared più a prova di proiettile. È grandioso, ma il mio lavoro come programmatore non è principalmente quello di farmi diventare un programmatore migliore, ma per scrivere programmi che funzionano, e così facendo, diventerò un programmatore migliore.

Allora, qual è il mio voto? Stai lontano dal GAC. Consenti a ciascuna applicazione di fare affidamento sulla versione dell'assembly su cui sono basati.Un bug esposto in quell'assembly da un'applicazione potrebbe non apparire mai nelle altre applicazioni, perché stanno usando l'assembly in modo diverso, quindi lasciali stare e non dovrai eseguire il test di regressione 5 applicazioni distinte ogni volta che la tua DLL condivisa viene rattoppata .

Answer 2

Io uso la seguente strategia debole.
Utilizzare GAC - quando programmi diversi utilizzano assemblaggio condiviso + controllo delle versioni.
Non utilizzare GAC - sempre.

qualsiasi commento è benvenuto.