2016-02-21 1 views
9

Comme je le comprends actuellement dans le .NET Framework complet lorsque nous installons le cadre à la machine, il déploie le BCL entier au GAC de l'ordinateur. De cette façon, lorsque nous développons un logiciel avec .NET et que nous le déployons sur cet ordinateur, il utilise les assemblages BCL qui sont disponibles dans le GAC lors de l'installation de .NET Framework lui-même. Maintenant, comme je sais que CoreFX est l'équivalent de la BCL pour le nouveau noyau .NET. La principale différence, cependant, est que nous pouvons spécifier dans le project.json exactement quels morceaux du CoreFX nous avons besoin.Existe-t-il un équivalent GAC pour .NET Core?

Ma question est la suivante: lorsque nous déployons des applications .NET Core, y a-t-il un équivalent GAC dans l'environnement de production? Ainsi, lorsque nous déployons l'application à exécuter, y a-t-il un emplacement central dans l'ordinateur sur lequel l'application cherchera à voir si tout le CoreFX est disponible?

+0

compilation AOT (Ahead-Of-Time) est susceptible d'être la voie dominante pour créer executables déployables, aucun cadre nécessaire du tout. Assez nécessaire pour ne pas être tué par des démarrages à froid. Ils y travaillent, projet CoreRT. Ce genre de questions est beaucoup plus utile lorsque vous leur posez une question dans un an. –

+0

J'ai vu que CoreRT serait responsable de faire cette compilation AOT qui à la fin produirait juste un exécutable natif. Mais il y a aussi le CoreCLR qui fonctionne avec la compilation JIT, n'est-ce pas? Dans ce cas, si on l'utilise, y a-t-il quelque chose comme le GAC où les assemblages du CoreFX seront recherchés? – user1620696

Répondre

3

Non, pas comme vous le pensez du GAC. Les applications de base sont conçues pour être isolées les unes des autres, de sorte que vous pouvez en patcher une sans crainte d'affecter les autres. Vous expédiez tous les paquets dont vous avez besoin avec l'application.

Il existe un répertoire de maintenance qui peut être utilisé pour expédier des mises à jour pour les composants Core, mais pour les échanger complètement, ne pas activer le versioning côte à côte et uniquement pour les mises à jour livrées via Microsoft Update.

+0

Merci @blowdart. Je savais que pour .NET Core, nous pourrions expédier tous les paquets dont nous avions besoin avec l'application, mais je pensais que c'était juste une option. Donc, lorsque nous développons des applications .NET Core, nous devons * toujours * expédier les paquets avec l'application? – user1620696

+0

Il y a le concept d'un cache local, ou du moins il y en avait avec DNX, mais quand vous expédiez localement, vous le surchargez. C'est plus pour les paquets "manquants". – blowdart

9

Modifier 2017-09-01

Un peu analogue au GAC, .NET Core 2.0 introduit le "Runtime package store":

A partir de .NET Core 2.0, il est possible d'emballer et déployer des applications sur un ensemble connu de packages existant dans l'environnement cible. Les avantages sont des déploiements plus rapides, une utilisation moindre de l'espace disque et des performances de démarrage améliorées dans certains cas.

Cette fonctionnalité est implémentée en tant que magasin de packages d'exécution, qui est un répertoire sur le disque où les packages sont stockés (généralement/usr/local/share/dotnet/store sur macOS/Linux et C:/Program Files/dotnet/stocker sur Windows).


Vous êtes à la recherche d'un "déploiement dépendant-cadre". De the docs:

Vous pouvez créer deux types de déploiements pour les applications de base .NET:

  • déploiement dépendant du cadre. Comme son nom l'indique, le déploiement dépendant du framework (FDD) dépend d'une version partagée du système .NET Core pour être présente sur le système cible. Parce que .NET Core est déjà présent, votre application est également portable entre les installations de .NET Core. Votre application contient uniquement son propre code et toutes les dépendances tierces situées en dehors des bibliothèques .NET Core. Les FDD contiennent des fichiers .dll qui peuvent être lancés en utilisant l'utilitaire dotnet à partir de la ligne de commande. Par exemple, dotnet app.dll exécute une application nommée app.

  • Déploiement autonome. Contrairement au FDD, un déploiement autonome (SCD) ne repose sur aucun composant partagé présent sur le système cible. Tous les composants, y compris les bibliothèques .NET Core et l'environnement d'exécution .NET Core, sont inclus dans l'application et sont isolés des autres applications .NET Core.Les SCD incluent un exécutable (tel que app.exe sur les plates-formes Windows pour une application nommée app), qui est une version renommée de l'hôte .NET Core spécifique à la plate-forme et un fichier .dll (app.dll), qui est l'application réelle.