Impossible pour Visual Studio 2017 d'installer le package Nuget dans un projet .NET 4.7
Je reçois le message d'erreur suivant lors de la tentative d'installation d'un paquet Nuget dans un projet .NET Framework 4.7 standard:
Le chemin, le nom de fichier ou les deux spécifiés sont trop longs. Le nom de fichier complet doit comporter moins de 260 caractères et le nom de répertoire moins de 248 caractères.
J'utilise Visual Studio 2017 15.3.3 Enterprise (le plus récent et le plus performant).
Étant donné que ceci est mon paquet, j'ai le contrôle total sur le code source. Ce qui est intéressant, c’est que j’ai utilisé ce paquet dans le passé sans changer le nom, mais pour ce tour, je l’ai reconstruit pour ajouter une fonctionnalité et je reçois maintenant cette erreur.
Ce qui est encore plus intéressant, c’est que j’ai des paquets de la même bibliothèque, avec les mêmes conventions d’espace de noms, avec plus - noms, qui fonctionnent parfaitement et qui ont été installés dans ce même projet sans aucun problème.
J'ai déjà essayé de réduire le nom du paquet, les noms de classe dans le paquet lui-même, de nettoyer le répertoire de construction, de nettoyer le paquet depuis le serveur Nuget (c'est un serveur local avec le dernier serveur Nuget.server installé qui fonctionne normalement très bien) ), et même effacer le répertoire bin du projet en question, effacer TOUS les répertoires bin de TOUS les ancêtres du paquet "incriminé", vider le cache du paquet, redémarrer l'ordinateur et reconstruire l'intégralité de la chaîne de paquets de nugets , Tout en rien. Un des MVP du MS m'a dit "qu'ils ont réglé le problème". Apparemment non.
Toute aide serait appréciée ici, je suis à bout de ressources et n’ai plus d’idées à essayer.
Merci.
OK, big Merci @danmosemsft qui a suggéré de fouiller avec le moniteur de processus SysInternals. Après avoir joué un peu avec cela, j'ai enfin trouvé le moyen de réduire le jeu de résultats à une activité de fichier. Ce que j'ai remarqué, et les ingénieurs de nuget devraient en prendre NOTE: le problème n'était PAS un nom de projet trop long, mais plutôt, nuget tentait de mettre à jour un paquet qui n'était plus là. Pourquoi est-il parti est un mystère qui reste à résoudre. Je reste normalement en dehors du répertoire packages et je ne me mêle pas du fichier packages.config. Je (pense} _ que cela pourrait être dû à mon impatience d'attendre le début de VS, de charger tous les goodies et de me permettre ensuite d'effectuer une "Gestion des paquets NuGet" - mettre à jour tout. Je me souviens d'avoir vu une mise à jour de NUnit ou de FluentAssertions qui souhaitait effectuer une activité de fichier supplémentaire en plus de l'installation de la version suivante, un script je crois. Je ne peux pas en parler avec assurance, je ne faisais pas trop attention, car les mises à jour tierces "ne fonctionnent que". Je n'ai pas vu la ligne "fini" de NuGet, alors je pense que c'était la racine de mon problème. Plutôt que d’attendre que VS se soit calmé, j’ai poussé un peu (hé, les boutons ont répondu alors il y a ne devrait pas y avoir de problèmes ...).
En conséquence, le répertoire packages était complètement rempli d'anciennes choses qui n'y appartenaient PAS. Donc, j'ai nettoyé manuellement tout ce qui était cruel, nettoyé manuellement le fichier packages.config, redémarré VS, attendu qu'il se soit calmé, effectué mes mises à jour de NuGet et mon alto! aucun problème - N'AYANT PAS CHANGÉ AUCUN DES NOMS DES PAQUETS ANCESTRAUX PAR UN MÊME CARACTÈRE.
Alors, qu'est-ce que j'en conclus? C’est ma conviction, et les gars qui construisent réellement nuget et nuget.server devraient examiner de plus près les erreurs commises, de sorte que je pense que l’erreur est moins une erreur de chemin trop long, c'est plutôt un "hé, je n'ai pas trouvé le fichier auquel je m'attendais, alors le nom du fichier est plein de bric-à-brac (et probablement trop long maintenant), donc je vais lancer une erreur qui dit que c'est trop long et que j'arrête". C'est apparemment un échec pour gérer un paquet/répertoire de paquet manquant qui cause ce problème particulier
J'ai résolu mon problème en veillant à ce que tous les répertoires de paquets soient exempts de tout courrier indésirable et à les reconstruire à partir d'une source propre. Mon problème est maintenant résolu.
Merci à tous ceux qui ont répondu.
Mise à jour: Bien que ce qui précède ait contribué à la solution, ce n'était PAS la réponse. Voici la séquence d'événements qui ont conduit à ce problème et à sa résolution ultime ... La solution a été créée dans le répertoire C:\Utilisateur\Sam\Documents\Visual Studio 2017\Projects avec le nom spécifié de AWE.Lib.ADO. .MsSqlSvr.ServerEntityHandler. Cela a fonctionné très bien, pas d'erreur. Cependant, en raison d'un changement de schéma de nommage à partir du niveau haut, le répertoire racine de ce projet a été remplacé de "C:\Utilisateur\Sam\Documents\Visual Studio 2017\Projets" par "C:\Utilisateur\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x ". Aucun problème, pensais-je, étant donné qu'un collègue qui est également un MVP de MS m'a dit que toutes les restrictions de longueur de nommage avaient été supprimées dans VS 2017. Alors ... j'ai déplacé le projet de son domicile actuel vers le répertoire spécifié. Compile très bien, apporte les paquets de nuget MIS À JOUR MAIS DÉJÀ INSTALLÉS, etc.
Ou alors j'ai pensé. Lorsque j'ai eu besoin d'ajouter un package de nuget NOUVEAU (un package qui ne faisait pas partie de la solution auparavant), j'ai reçu l'erreur ci-dessus. Il s'avère que le nouveau nom de la solution de réception comporte quelques caractères de plus que ce que VS acceptera. Les restrictions de longueur de dénomination sont STILL IN PLACE.
Comment ai-je finalement résolu le problème: Après avoir lutté contre cela, j'ai levé la main et décidé de tout recommencer - un véritable Fichier | Nouveau. J'ai donc démarré avec une nouvelle solution nommée comme suit: .__ "C:\Utilisateurs\Sam\Documents\Visual Studio 2017\Projets\DotNet_4.7\AWE 8.x\AWE.Lib.ADO.MsSqlSvr.HndlrServerEntity" Cela génère une erreur - nom trop long. Je me suis demandé l'erreur de Nuget en ce sens qu'elle spécifie que le nom doit comporter moins de 248 caractères ou 260 maximum.
Ce que je suis autorisé à utiliser dans le nouveau dialogue de solution est le suivant: "C:\Utilisateurs\Sam\Documents\Visual Studio 2017\Projets\DotNet_4.7\AWE 8.x\AWE.Lib.ADO.MsSqlSvr.HndlrServerEnt", pour un total de 106 caractères. Si le répertoire est raccourci, je peux ajouter à la longueur du nom. Si je raccourcis la longueur du nom de la solution, VS l’acceptera. Tant que la longueur totale du répertoire plus le nom de la solution est inférieure ou égale à 106 caractères, il n'y a pas de problème.
Le problème provient de la création de la solution à un emplacement donné et de son fonctionnement correct à tous égards, du déplacement de cette solution vers un répertoire différent, tout en conservant sa fonction (je n'ai PAS eu besoin d'ajouter de nouveaux paquets de pépites pour le moment), puis essayez d’ajouter un nouveau paquet de pépites au mélange après le déménagement. C’est ce qui a déclenché l’erreur susmentionnée.Alors… le «correctif» ultime, utilisez un nom plus court car il semble que 106 caractères soient la limite malgré les messages d'erreur (et ce que le MVP MS m'a dit/dit).
So...the ultimate "fix", use a shorter name as it seems that 106 characters is the limit despite what the error messages are saying (and what the MS MVP was told/told me).
Il existe une autre raison pour laquelle le compilateur a envoyé ce message d'erreur . Pendant la construction, assurez-vous que le code source est placé dans un dossier de moins de 260 caractères . Par exemple, un chemin tel que C:\Users\User\source\Services\Exp\Sample-web-application-indot-net-displaying-RestAPI\Sample-web-application-indot-net-displaying-RestAPI\SportsStore est d'environ 150 caractères longs, mais la solution contient des sous-dossiers contenant à leur tour des fichiers de code source, etc. . Parfois, la longueur totale du chemin de certains fichiers dépasse la longueur de 260 caractères.
Je pense que les futures versions de Visual Studio auront une indemnité de longueur supérieure. Jusque-là, nous pouvons nous assurer que nos noms de fichiers ne sont pas trop longs.
Je rencontrais le même problème après avoir déplacé un projet dans un autre dossier. Dans mon cas, j'ai fermé VS qui a renommé le dossier .vs en racine en 1.vs (en le supprimant efficacement) et en rouvrant mon projet.
Cette erreur me vient lorsque j'ai essayé de copier le dossier du projet sur OneDrive et le problème est que OneDrive ne télécharge pas de fichiers de noms longs.
J'ai résolu ce problème en copiant simplement le dossier du projet, puis en le collant dans le nouvel ordinateur portable via USB.
Je souhaite que cela pourrait aider