Quando e quando-non installare nel GAC?

Question

Quando è necessario installarlo nel GAC e quando no? (Mi riferisco, davvero, all'installazione sul computer di un cliente quando hanno acquistato i nostri prodotti).

1. Ho un assembly che verrà utilizzato solo con la mia unica applicazione (GAC o no-GAC)?

2. Ho un assembly condiviso da tutte le mie applicazioni (GAC o no-GAC)?

3. Tutte le mie applicazioni possono utilizzare versioni diverse del mio assembly (GAC o no-GAC)?

Questi sono tre scenari ... ma sono sicuro che ce ne sono altri. Non sto necessariamente cercando una risposta solo a queste tre domande.

Domanda simile: What sono i vantaggi e gli svantaggi dell'utilizzo del GAC?

Answer 1

Linee guida generali per gli Stati membri

1. no
2. no
3. no

GAC è davvero un repository per le librerie .NET comuni di Microsoft. Sì, consentono anche agli sviluppatori di usarlo, ma come regola generale, se non hai bisogno di GAC, non usarlo. mantieni le cose semplici e locali se non fanno male.

• Vorrei considerare GAC solo per motivi di prestazioni, ad esempio se si dispone di alcuni assiemi enormi, provare a inserirli in GAC e NGEN . Dovrebbe aumentare significativamente le prestazioni. Microsoft lo fa per tutti gli assembly .NET framework standard durante l'installazione (ora sai perché l'installazione richiede così tanto tempo). Anche Paint.NET lo fa (per migliorare i tempi di avvio della propria app). Tuttavia la maggior parte di noi non lavora su enormi framework o concorrenti di photoshop, quindi la maggior parte delle volte, i guadagni in termini di prestazioni derivanti dall'assemblaggio in GAC sono minimi. Non vale la pena rinunciare alla semplice distribuzione di x-copy.

• Alcuni sviluppatori potrebbero utilizzare GAC per assicurarsi che gli utenti con privilegi insufficienti non possano eliminare o modificare i loro assembly.

• Per altri potrebbe essere per ragioni di versioning ma qui dovresti davvero riconsiderare. Non ripeterò quanto è stato già detto, puoi leggere qui perché .

E non dimenticare che una volta che vuoi implementare GAC, il tuo installatore avrà bisogno dei privilegi di amministratore, puoi praticamente dimenticare la distribuzione click-once, ecc ...

Answer 2

Casi utili per GAC:

• Codice richiamabile COM - ovvero se si desidera che un codice non.NET sia in grado di accedervi senza interferire con le DLL ecc.
• Componenti revisionati (COM +)
• Se stai scrivendo un codice così comune, è effettivamente utile utilizzare GAC, principalmente componenti .NET framework ecc.
• Se si desidera utilizzare NGEN per pre-JIT il codice

A parte questo, tendo ad evitare il GAC come la peste. È molto più semplice distribuire le DLL necessarie con la tua app tramite robocopy ecc; questo offre isolamento e facile implementazione.

Answer 3

Se stai installando applicazioni web asp.net e sei il proprietario e hai il controllo completo sulla macchina, in alcuni casi potrebbe avere senso mettere i tuoi assembly, che prevedi condividi tra siti / istanze web nella Global Assembly Cache.

È possibile migliorare notevolmente il tempo di caricamento iniziale e l'utilizzo della memoria dell'applicazione su server che hanno molte istanze multiple delle stesse applicazioni ASP.NET se si inseriscono gli assembly nel GAC. Almeno l'ho visto sui nostri server con dozzine di installazioni.

Answer 4

Se stai spedendo una libreria riutilizzabile composta da più assiemi, ma solo pochi di essi formano una facciata, puoi prendere in considerazione l'installazione degli assiemi in GAC, se il pacchetto è installato sui PC degli sviluppatori.

Immagina di spedire 6 assemblaggi e solo uno di questi 6 assemblaggi contiene una facciata, ovvero altri 5 vengono utilizzati solo dalla facciata stessa. Spedisci:

• MyProduct.Facade.dll : questo è l'unico componente destinato ad essere utilizzato dagli sviluppatori
• MyProduct.Core.dll - utilizzato da MyProduct.Facade.dll, ma non destinato all'uso da parte degli sviluppatori
• MyProduct.Component1.dll - lo stesso
• MyProduct.Component2.dll - lo stesso
• ThirdParty.Lib1.dll - libreria di terze parti utilizzata da MyProduct.Component1.dll
• ThirdParty.Lib2.dll - lo stesso
• ecc.

Gli sviluppatori che utilizzano il tuo progetto vorrebbero fare riferimento solo a MyProduct.Facade.dll nei propri progetti. Ma quando il loro progetto viene eseguito, deve essere in grado di caricare tutti gli assembly a cui fa riferimento - in modo ricorsivo. Come si può ottenere questo? In generale, devono essere disponibili nella cartella Bin, in GAC:

• È possibile chiedere agli sviluppatori di individuare la cartella di installazione e aggiungere riferimenti a tutti gli N assiemi inseriti. Ciò garantirà che vengano copiati nella cartella Bin per essere disponibili in fase di esecuzione.
• È possibile installare il modello di progetto VS.NET già contenente questi 6 riferimenti . Un po 'complesso, dato che dovresti iniettare il percorso effettivo dei tuoi assembly in questo modello prima della sua installazione. Questo può essere fatto solo dall'installatore, poiché questo percorso dipende dal percorso di installazione.
• Puoi chiedere agli sviluppatori di creare un passaggio speciale post-build nel file .csproj / .vbproj copiando le dipendenze necessarie nella cartella Bin. Gli stessi svantaggi.
• Infine, puoi installare tutti i tuoi assembly in GAC . In questo caso gli sviluppatori devono aggiungere il riferimento solo a MyProduct.Facade.dll dal loro progetto. Tutto il resto sarà comunque disponibile in fase di esecuzione.

Nota: l'ultima opzione non ti fa fare lo stesso durante la spedizione del progetto ai PC di produzione. Puoi spedire tutti gli assemblaggi nella cartella Bin o installarli in GAC - tutto dipende da tutto il tuo desiderio.

Quindi la soluzione descritta mostra il vantaggio di inserire assiemi di terze parti in GAC durante lo sviluppo. Non riguarda la produzione.

Come è possibile notare, l'installazione in GAC ha principalmente lo scopo di risolvere il problema della posizione degli assiemi richiesti (dipendenze). Se un assembly è installato in GAC, è possibile considerare che esiste & Quot; vicino & Quot; qualsiasi applicazione. È come aggiungere il percorso a .exe alla variabile PATH, ma in & Quot; modo gestito & Quot ;. - ovviamente, questa è una descrizione piuttosto semplificata;)

Answer 5

Ecco il link di Chris Sells chiamato " Evita il GAC "

https://sellsbrothers.com/12503

La spiegazione è piuttosto lunga, ma in breve, i due casi che identifica sono

1. Correzione di bug critici senza toccare le app interessate (e senza interrompere nulla!)

2. Tipi di condivisione in fase di esecuzione tra assiemi distribuiti separatamente

Nota: c'è una discussione molto lunga alla fine del post di Chris , un elenco molto bello di commenti.

Answer 6

prima se stai installando questo su un computer client dovrai aggiungere un'azione personalizzata per installare l'app nel GAC e un'altra durante la rimozione.

sul caso A sicuramente non GAC

sul caso B se la tua libreria cambierà costantemente dovrai aggiungere ogni versione dell'assembly in gac ogni volta e si verificherà l'aggiornamento a quell'assemblaggio

sul caso C l'esecuzione affiancata consente di eseguire diverse versioni dell'assieme e non è necessario aggiungere nulla per differenziare le versioni.

Utilizzato solo se è necessario

Answer 7

Ha senso installarlo nel GAC solo se molte e molte applicazioni Web sullo stesso server condivideranno esattamente le stesse librerie. Ad esempio, su un server Sharepoint possono essere presenti centinaia di siti Web che devono tutti condividere la stessa web part, quindi in questo caso ha senso distribuire la web part compilata nel GAC.