Esiste un equivalente GAC per .NET Core?

Question

Come attualmente comprendo nel completo .NET Framework quando installiamo il framework sulla macchina, distribuisce l'intero BCL al GAC del computer. In questo modo, quando sviluppiamo un software con .NET e lo distribuiamo su quel computer, utilizzeremo gli assembly BCL resi disponibili nel GAC quando lo stesso .NET Framework è stato installato.

Ora, come so che CoreFX è l'equivalente del BCL per il nuovo .NET Core. La differenza principale, tuttavia, è che possiamo specificare nello project.json esattamente quali pezzi del CoreFX abbiamo bisogno.

La mia domanda è: quando installiamo app .NET Core, esiste un equivalente GAC nell'ambiente di produzione? Quindi, quando distribuiamo l'app da eseguire, c'è una posizione centrale nel computer in cui l'app guarderà per vedere se l'intero CoreFX è disponibile?

Answer 1

No, non c'è, non nel modo in cui si pensa al GAC. Le app di base sono pensate per essere isolate l'una dall'altra, in modo da poterle applicare una patch senza temere di influenzare le altre. Spedisci tutti i pacchetti necessari con l'app.

Esiste una directory di manutenzione che può essere utilizzata per spedire gli aggiornamenti per i componenti principali, ma è per sostituirli completamente, non abilitare il controllo delle versioni affiancate ed è solo per gli aggiornamenti spediti tramite Microsoft Update.

Answer 2

Modifica 2017-09-01

Un po 'analogo al GAC, .NET 2.0 introduce il core "Runtime package store":

A partire con .NET core 2.0, è possibile confezionare e distribuire app su un set noto di pacchetti che esistono nell'ambiente di destinazione. I vantaggi sono distribuzioni più veloci, minore utilizzo dello spazio su disco e prestazioni di avvio migliorate in alcuni casi.

Questa funzione è implementata come un pacchetto di runtime, che è una directory sul disco in cui sono memorizzati i pacchetti (in genere su/usr/local/share/dotnet/store su macOS/Linux e C:/Programmi/dotnet/negozio su Windows).

---

Siete alla ricerca di una "distribuzione Framework-dipendente". Da the docs:

È possibile creare due tipi di implementazioni per applicazioni core NET:

• distribuzione Framework-dipendente. Come suggerisce il nome, la distribuzione dipendente dal framework (FDD) si basa su una versione condivisa a livello di sistema di .NET Core per essere presente sul sistema di destinazione. Poiché .NET Core è già presente, la tua app è anche portabile tra le installazioni di .NET Core. La tua app contiene solo il proprio codice e eventuali dipendenze di terze parti al di fuori delle librerie .NET Core. I FDD contengono file .dll che possono essere lanciati usando l'utility dotnet dalla riga di comando. Ad esempio, dotnet app.dll esegue un'applicazione denominata app.

• Implementazione autonoma. A differenza di FDD, una distribuzione autonoma (SCD) non si basa su componenti condivisi presenti sul sistema di destinazione. Tutti i componenti, incluse le librerie .NET Core e il runtime .NET Core, sono inclusi con l'applicazione e sono isolati da altre applicazioni .NET Core.Le SCD includono un eseguibile (come app.exe su piattaforme Windows per un'applicazione denominata app), che è una versione rinominata dell'host .NET Core specifico della piattaforma e un file .dll (ad esempio app.dll), che è l'applicazione effettiva.