0

J'ai une solution avec plusieurs projets, par exemple disons que 10 projets liés aux tests ont une dépendance vis-à-vis de nunit. Actuellement, ma structure de la solution inclut des dossiers pour Tools et Lib, alors peut-être que le téléchargement complet des nunits se trouve dans Tools et juste le dll dans Lib. Je suppose que tout gestionnaire de paquets (NuGet et OpenWrap étant deux que je regarde) doit créer son propre emplacement «connu» pour les paquets. Donc, alors que le mode de gestion des paquets à l'ancienne, après la mise à jour manuelle de mon dossier Lib, je sais que chaque projet qui avait une dépendance sur nunit vient d'être mis à jour.gestionnaires de paquets, structure de projet et migration

Mais si je mets à jour avec un gestionnaire de paquets, je dois visiter chaque projet pour m'assurer qu'il est mis à jour et pointant vers la même référence, oui? Et certaines dll ne sont peut-être pas trouvées (je pense à unHAddins en ce moment) donc vous n'êtes pas complètement libéré de la gestion manuelle des paquets. La migration vers les dernières mises à jour n'est pas terminée jusqu'à ce que chaque projet soit mis à jour par le gestionnaire de paquets.

Je me demande donc si je comprends bien, quelle est la meilleure approche pour intégrer la gestion des paquets dans une solution de bonne taille est - par exemple:

0) add to source control: NuGet 'packages' folder or OpenWrap 'wraps' folder 
1) pick a dll (start with one that you beleieve has minimal dependencies) 
2) pick a project (ideally with minimal dependencies that might break) 
3) if OpenWrap, get the package you want into 'wraps' 
4) for each project: 
    a) add reference to subject dll (manually if OpenWrap, NuGet will add for you) 
    b) fix compile error as needed 
    c) run tests 

Est-ce que son droit?

Cheers,
Berryl

Répondre

1

Pour répondre à vos questions, ne vous n'avez pas à faire quoi que ce soit avec openwrap, tous les projets importer toutes les dépendances dans un champ, de sorte que la mise à jour concerne tout.

Je ne peux pas répondre pour les autres gestionnaires de paquets, mais dans openwrap, vous ajoutez le dossier/wraps dans le contrôle source avec les paquets qui ont été retirés lorsque vous les avez ajoutés ou mis à jour. Le processus consiste à ajouter d'abord le paquet à partir d'un dépôt distant (ou à en créer un à partir de vos assemblages existants s'il n'y en a pas), et à supprimer manuellement les références de/lib. Dans OpenWrap, nous n'ajoutons pas les références à votre csproj, nous les ajoutons au moment de la construction, donc s'il y a déjà une dépendance dans/lib, nous ne l'ajouterons pas. Cela signifie que vous pouvez ajouter tous les packages et supprimer les références l'une après l'autre, en exécutant vos tests à chaque fois.

Heureusement, il s'agit d'un problème temporaire jusqu'à ce que toutes les DLL soient disponibles en tant que paquets, ce qui arrivera plutôt rapidement.

+0

Merci, Sebastion - J'ai mis à jour mon flux de processus cheesy en conséquence. – Berryl

+0

Tenez-vous, quelque chose ne va pas ici, parce que je ne peux pas construire mon projet dans VS qui essaie d'utiliser log4net. C'est parce qu'il n'y a pas de référence dans csproj. Aussi je ne pouvais pas trouver un seul tutoriel qui pourrait expliquer ce problème, votre introduction saute simplement cette étape - je veux dire la partie "oh et ici vous pouvez voir que VS ne se plaint plus de log4net - plus de couleur rouge". Dans mon projet, la couleur rouge reste et je ne peux pas compiler. –

+0

Ok, je peux voir, ce qui est évident pour moi maintenant, que le problème était que je n'avais pas utilisé de noms de types complets ce qui a causé le problème de compilation. Cependant, je vois 2 problèmes: 1) toujours mon R # se plaint de ne rien comprendre de l'assemblage de log4net (en rouge) 2) Je ne veux pas qualifier complètement tous les types de bibliothèques gérées par OpenWrap –

Questions connexes