NuGet problèmes avec des forfaits.config, des références de projet et la solutionwide dossier packages

Nous commençons à utiliser NuGet et nous avons quelques questions:

Tout d'abord, quelques NuGet faits:

(Juste pour s'assurer que nous avons bien compris les locaux pour combien de NuGet œuvres)

• Les paquets.config (situé dans le projet de la racine) est créé et mis à jour en cas d'ajout, de mise à jour ou supprimer des packages. Dans ce fichier la version de package de propriété reflète la version complète qui est en cours d'utilisation, donc, dans ce sens, c'est aussi un état. Il est possible d'ajouter le allowedVersions propriété à la spécification de paquetage, qui est alors une restriction sur les versions qui peuvent être mis à jour. Pour faire de paquet travaux de restauration, ce fichier doit être sous contrôle de code source.
• Le dossier packages est situé dans la solution de la racine et contient une version téléchargée de tous les paquetages dépendants dans un sous-dossier nommé pour faire correspondre les noms de package (y compris la version), pour permettre à de multiples versions d'un même paquet à être utilisé par les différents projets dans un environnement multi-projet de solution. Il est conseillé de ne pas la source de contrôle de ceux-ci car ils sont binaires et le fait que le paquet de restauration peut les recréer en cas de besoin. Quand un paquet est mis à jour un nouveau dossier qui correspond à la mise à jour est créé avec le package.
• Le projet-les fichiers contient une référence à l'packages dans le dossier, dans l'ordre pour les versions de travail et pour visual studio également être en mesure de fournir de saisie semi-automatique, intellisense et plus. Quand un paquet est mis à jour les références dans le fichier projet sont mis à jour pour correspondre à la nouvelle de l'emplacement du package dans le dossier packages.

Questions:

1. Puisque les paquets.fichier de configuration du package entrées contient la version complète-info nous avons constamment besoin de mettre à jour le contrôle de la source repo avec les changements. Ou, nous pourrions ignorer les modifications, la plupart du temps, mais quand tout simplement la version a changé nous (dans la plupart des cas) être en mesure de les ignorer.
   Cela semble très inutile, car la NuGet restauration doit être en mesure de connaître les versions sont autorisés (via allowedVersions).
2. La allowedVersions propriété doit être ajouté manuellement, quelque chose qui est facilement oublié. Nous sommes à l'aide de la sémantique des versions, donc, pour nous, lors de l'installation c'est à dire un Foo-version 1.1.0, allowedVersions="[1,2)" devrait être implicite.
3. Lors de l'ajout de la allowedVersion puis de package NuGet restauration ne semble pas être en mesure de trouver -version préliminaire assemblées (peut-être un bug?).
4. Pourquoi les packages gérés par NuGet sur le niveau de la solution? Si vous travaillez dans un mix-and-match solution, qui contient un projet-Un (repo-1) et le projet B (repo-2), alors le niveau de la solution d'emballage n'est pas d'aller travailler. C'est, Si vous enregistrez ce fichier de solution dans un emplacement distinct, les choses pourraient encore travailler autant que je sache. Mais, si vous puis de mettre en place une autre solution qui contient du projet (repo-1) et le projet-C (repo-3), puis de projet-Un soudain besoin d'un package-restauration, et le pire, les références de projet serait modifiée pour correspondre à la dernière modification. Revenir à la première solution sera alors à avoir des références qui ne fonctionne pas. La vérification de ces aura certainement à eux de ne pas travailler pour les autres.
5. Sur un package de mise à jour, le fichier projet références sont mises à jour (pour correspondre à la nouvelle foldernames avec versionid) et apparaît comme une modification non validée. Les auteurs de cette modification semble être la norme, mais, à notre avis, cela ne devrait pas être nécessaire.

Notes sur ExcludeVersion (qui pourrait être proposé comme une solution pour le problème ci-dessus:

• Vous ne pouvez fournir cette option lorsque vous effectuez manuellement NuGet commandes, autant que je sache. Lors de l'installation/la mise à jour des paquets via NuGet menus dans Visual Studio qui ne peut pas être utilisée. Utilisant l'un des outils automatisés signifie que le nom du dossier et du projet de référence qui doit être corrigé manuellement par la suite.
• Nous savons que ExcludeVersion n'est pas le paramètre par défaut, probablement en raison de l'appui le cas où quelqu'un travaille dans un multi-projet de solution, où les différents projets dépendent de différentes versions d'un même ensemble.

Solutions possibles?

(Mais, ce qui peut nécessiter des changements importants dans la NuGet écosystème?)

A - paquets.config

Je souhaite que chaque élément de package dans des packages.config pourrait fossé allowedVersions et, au lieu de changer de version de la gamme spécificateur. Les paquets élément doit également fournir un moyen d'identifier séparément la source pour obtenir les mises à jour. Enfin, si un paquet installé suit Sémantique Versioning alors la propriété de version devrait automatiquement le programme d'installation de la version portée en fonction de la version installée.

Exemples de packages.config:

`<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Foo" version="[1,2] source="Development Feed">
</packages>`

Ce serait:

• Résoudre le problème avec excessive des validations de l'emballage.fichier de config, depuis la version propriété n'est plus constamment mis à jour.
• Nul besoin de rappeler à l'ensemble de la gamme pour sémantiquement versionnées projets.
• S'assurer que les colis sont extraits de l'avance désirée et que le temps n'est pas gaspillé par la recherche dans les sources erronées.

B - dossier Packages et les noms des packages installés dans

Je souhaite que le dossier packages était situé dans chaque projet de la racine et que les noms de sous-dossiers a été limitée à la nom-du-paquet, à l'exclusion de la version.
Ce serait:

• Résoudre le problème avec trop s'engage du projet-fichiers, puisque les références de projet dans le fichier projet pointe maintenant vers le même paquet-dossier après une mise à jour.
• Permet aux projets d'utilisation des différentes versions d'un même paquet, car ils sont vraiment indépendants les uns des autres.

---

Nous serions très heureux d'entendre parler de solutions aux problèmes répertoriés.

OriginalL'auteur Spiralis | 2014-01-30