asp.net core 2.0 publish génération de lots hors DLL
Une seule application de programmation quelques mois et à chaque fois que je publiais mon projet, elle générait 19 éléments (sans fichiers wwwroot). Et à partir d'aujourd'hui, il génère 202 fichiers avec beaucoup de .dll (sans fichiers wwwroot). Je n'ai aucune idée de ce qui s'est passé ou de ce que j'ai fait. Mon application utilisant .NET Core 2.0. Je ne sais pas quelles informations sur mon projet sont pertinentes. Environ 81/202 fichiers ne sont que des bibliothèques Microsoft.AspNetCore et 43/202 ne sont que des bibliothèques Microsoft.Extensions. J'ai essayé supprimé obj, bin, propriétés et node_modules et toujours le même problème. Après avoir téléchargé uniquement les fichiers générés auparavant à partir de nombreux fichiers, tout a fonctionné. Je pense que ce n'est pas nécessaire .dll mais je n'ai aucune idée pourquoi asp.net les génère toujours. Merci pour tout conseil.
ÉDITER:
Voici une grande capture d'écran de la sortie de publication, des dépendances et de la sortie de publication ajoutée à la demande de l'un des utilisateurs qui a commenté cette question: 
ÉDITER:
J'ai obtenu une nouvelle erreur après avoir modifié les propriétés de publication des déploiements autonomes en déploiements dépendant du framework et j'ai une nouvelle erreur de sortie:
C:\Program Files\dotnet\sdk\2.1.400-preview-009063\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(125,5): Error NETSDK1068: The framework-dependent application Host requires a target framework of at least 'netcoreapp2.1'.
ÉDITER:
Maintenant, j'ai essayé de créer un nouveau projet asp.net core 2.0 et j'ai essayé de publier. Même problème. Quelque chose ne va pas avec mon sdk ou je ne sais pas.
SOLUTION:
J'ai créé un nouveau projet avec la cible 2.1 et déplacé tous les fichiers source. Après avoir résolu quelques erreurs, tout fonctionne bien.
Sur Visual Studio 15.8.2, j'ai également eu ce problème. Malheureusement, je ne pouvais pas simplement mettre à niveau l'application car nous avons des restrictions de version d'exécution sur les serveurs déployés gérés en interne. Donc, même si je peux m'appuyer sur la dernière version du SDK (2.1.401), où l'application est déployée, il existe une ancienne version du SDK (2.1.100).
Les corrélations des versions SDK et Runtime pour .NET Core 2.0 peuvent être trouvées ici .
Mon problème s'est manifesté ainsi: la construction et la reconstruction ont réussi, mais la publication a échoué avec le message d'erreur Error NETSDK1068: The framework-dependent application Host requires a target framework of at least 'netcoreapp2.1'. J'ai appris de ici que la valeur par défaut est d'utiliser la dernière version installée.
À partir de .NET Core 2.0, les règles suivantes s'appliquent lors de la détermination de la version du SDK à utiliser:
- Si aucun fichier global.json n'est trouvé ou global.json ne spécifie pas de version SDK, la dernière version SDK installée est utilisée. La dernière version du SDK peut être une version ou une pré-version - le numéro de version le plus élevé gagne . (pas d'italique dans l'original)
Dans ce même article, j'ai appris à utiliser le global.json fichier pour corriger cette erreur. J'ai utilisé git-bash et cd 'd dans le répertoire de travail local pour l'application Web que j'essayais de publier. Le fichier csproj correspondant doit se trouver dans ce répertoire. De là, j'ai exécuté ce qui suit:
dotnet new globaljson --sdk-version 2.1.100
Maintenant, je peux utiliser les paramètres de configuration de publication suivants: - Configuration: version - Framework cible: netcoreapp2.0 - Mode de déploiement: dépendant du framework - Runtime cible: portable
Cela est dû à un bogue introduit dans la version 2.1.400 du SDK .NET Core. Voir la publication dépendante du framework ne fonctionne pas sur 2.1.400 # 9852
Il existe une solution de contournement: publiez via la ligne de commande et passez l'arg --self-contained false.
Exemple:
dotnet publish -f netcoreapp2.0 -c Release --self-contained false
Je suis à peu près sûr que vous sélectionnez simplement le mode de publication pour un déploiement autonome de sorte que la majorité des fichiers ne sont que des bibliothèques nécessaires pour exécuter un runtime isolé. Pour revenir à quelques fichiers à nouveau, il suffit d'avancer avec les déploiements dépendants du Framework (décrit le même document)