2014-04-18 5 views
21

J'ai un projet Visual Studio 2013 qui utilise Nuget. J'ai un fichier packages.config dans le répertoire racine de la solution, définissant les paquets Nuget que nous voulons installer. J'ai aussi un fichier nuget.config dans le répertoire racine de la solution, en définissant packageSources, ainsi que des paquetsSourceCredentials. L'une des sources de l'emballage est un dépôt privé pour notre entreprise.Visual Studio 2013 ignore nuget.config

Si j'ouvre une invite de commande dans ce répertoire racine de la solution, et tapez nuget restore cela fonctionne très bien, et est capable de frapper nos repos privés pour tirer dans certains des paquets personnalisés que nous utilisons. Mais si j'ouvre la solution dans Visual Studio 2013 et que je la compile, elle échoue lorsque j'essaie de télécharger nos paquets personnalisés, parce qu'apparemment, elle ignore notre fichier nuget.config, et ne connaît donc pas notre repo de nuget privé. .

Je pourrais aller dans Outils> Options et ajouter notre repo privé, mais nous essayons de faire tout dans la solution elle-même, de sorte qu'il construit hors-la-boîte sans configuration personnalisée nécessaire.

Pourquoi nuget.config est-il ignoré par VS 2013?

+3

Je suppose que vous savez déjà que Nuget recherche ses fichiers NuGet.config dans cet ordre: 1. .nuget \ nuget.config 2. se dirige récursivement de ce dossier de projet vers la racine. 3. le NuGet.config global qui devrait être à% appdata% \ NuGet \ nuget.config Ce dernier est votre fichier à l'échelle de l'ordinateur (par utilisateur), dans Users \ {nom-utilisateur} \ roaming, et c'est le fichier qui est effectué lorsque dans Visual Studio vous allez dans Outils> Options et ajoutez votre repo privé. Ainsi, vous pouvez accéder à cela dans PowerShell ou autre. – JamesWHurst

+0

@JamesWHurst Voulez-vous dire que Visual Studio n'honorera jamais les informations de nuget.config dans mon projet, et que j'ai besoin d'utiliser PowerShell pour modifier le fichier nuget.config global pour ajouter le repo à la place? –

+0

Cela fonctionne-t-il si vous déplacez votre nuget.config du même dossier que la solution vers un sous-dossier appelé .nuget (donc .nuget \ nuget.config)? –

Répondre

3

J'ai créé un nouveau projet avec la structure de répertoire suivante.

-ConsoleApplication1 
    -ConsoleApplication1 
    -ConsoleApplication1.sln 
    -nuget.config 

Avant d'ajouter le nuget.config je ne pouvais voir aucun de mes mises en pension privés lors de l'utilisation de la gestion des paquets NuGet pour la fonction de la solution. Lorsque j'ai ajouté le fichier nuget.config, j'ai pu voir mes nouveaux dépôts dans la boîte de dialogue. Je suis également en mesure de restaurer mes paquets en utilisant NuGet restaurer et d'une construction à l'intérieur VS 2013.

Mon nuget.config ressemble à ceci

<?xml version="1.0" encoding="utf-8"?> 
<configuration> 
    <packageRestore> 
     <add key="enabled" value="True" /> 
     <add key="automatic" value="True" /> 
    </packageRestore> 
    <packageSources> 
     <add key="nuget.org" value="https://www.nuget.org/api/v2/" /> 
     <add key="MyRepo" value="http://XX.XX.XXX.XX:81/host/repo" /> 
    </packageSources> 
    <activePackageSource> 
     <add key="All" value="(Aggregate source)" /> 
    </activePackageSource> 
</configuration> 

En fonction de votre problème décrit la seule chose que je peux penser est que vous avez peut-être précédemment tenté de désactiver la restauration de paquet Nuget à partir de votre projet avant d'utiliser la méthode de restauration des paquets à jour. Si vous ne dépassez pas la restauration du paquet de bombes à partir de chaque projet simultanément, il se peut qu'il reste une logique susceptible d'interférer avec la nouvelle méthode. Par exemple, si vous avez supprimé le dossier .nuget de votre solution, le fichier nuget.config pourrait toujours se trouver là et causer des conflits.

+0

Comment gérer le fichier nuget.config dans VS 2013 s'il est "au-dessus" de votre répertoire de solutions actuel? Pouvez-vous élaborer sur la structure de votre répertoire en termes d'où se trouve votre fichier nuget.config, en ce qui concerne l'emplacement des fichiers .sln et .csproj? Et à quoi ressemble votre vue Solution Explorer, pouvez-vous voir le fichier nuget.config alors? –

+0

Cela n'a aucun sens. Pourquoi aurait-on besoin de placer nuget.config au-dessus du répertoire de la solution, où, logiquement, il s'appliquerait à toutes les solutions. Cela ne peut pas être juste ... – crush

+0

Je crois qu'il est tout à fait logique de le placer au dessus de votre solution. Nous avons notre fichier de solution principal à la racine de notre tronc et notre fichier régulier NuGet.config s'y trouve. Cependant, nous avons également une structure de dossiers/Devs/UserXxx séparée sous le coffre où nos développeurs ont leurs propres solutions. Le problème est que ces solutions ne respectent pas les emplacements des paquets. De plus, notre solution utilise des projets d'un repo complètement différent qui devrait avoir son propre dossier de paquets. Cependant, NuGet n'autorise pas deux emplacements de paquetage à partir d'une seule solution, nous devons donc créer un emplacement commun pour tous les paquets. – MarqueIV

0

Est-ce que votre solution est un projet de site Web ou un projet d'application Web? Je pense que le projet de site Web ignore le fichier nuget.config.

18

Redémarrez Visual Studio après l'édition de NuGet.config!

J'ai remarqué que VS2012 ne reprend pas les modifications apportées à NuGet.config avant de le redémarrer.

+0

Je crois que c'était aussi le problème de mon projet 2015. Je pensais que j'avais redémarré à un moment donné et il ne s'est toujours pas enregistré, mais après avoir commencé à travailler, j'ai fait des tests approfondis et tout fonctionnait comme prévu tant que je redémarrais VS. – JoeBrockhaus

1

J'ai trouvé que si vous avez une solution multi-projets, avec les projets tous dans des dossiers sous le dossier de la solution, mettre NuGet.config dans un dossier de projet ne fonctionne pas. Il ne prend pas la source du paquet privé. Il fonctionne si vous mettez un NuGet.config dans le dossier de la solution.

C'est, ce ne fait pas travail:

  • Solution
    • ProjectA
      • ProjectA.csproj
    • ProjectB
      • ProjectB.csproj
      • NuGet.config

alors que ce fait travail:

  • Solution
    • ProjectA
      • ProjectA.csproj
    • ProjectB
      • ProjectB.csproj
    • NuGet.config

Je aussi trouvé e à l'option disableSourceControlIntegration ne fonctionne pas lorsque spécifié dans \NuGet.config. Cela ne fonctionne que dans .nuget\NuGet.config. J'ai donc deux fichiers de configuration pour ma solution, un à la racine qui contient la configuration de la source du paquet, et un dans le dossier .nuget avec l'option disableSourceControlIntegration.

Testé avec Visual Studio 2012 Update 5 et l'extension du gestionnaire de packages NuGet 2.8.5.