Référence du projet VS NuGet
Comment dois-je faire référence à un autre project A de project B dans la même solution?
Qu'est-ce que je gagne et qu'est-ce que je perds si:
- Ajoutez la référence à
project Acomme référence de projet. - Installez le package NuGet de
project Adansproject B.
Les choses qui me dérangeraient sont les dépendances de build, le versioning ..?
Ou cela détruit-il totalement le but d'une solution?
Avec la première approche, vous gagnez en simplicité, car vous n'avez pas besoin de générer une nouvelle version du package nuget ProjectA, chaque modification que vous y apportez (c'est-à-dire ProjectA.nupkg).
Cependant, avec la deuxième approche, vous gagnez en portabilité, car vous pouvez facilement partager le même package de nuget avec d'autres projets/solutions.
Personnellement, je crée des packages nuget uniquement pour des projets dont le but est de partager avec d'autres solutions. (Par exemple, bibliothèques et frameworks).
J'espère que cela vous aidera à décider!
Référence du projet VS NuGet
La référence de projet ou NuGet est un problème très courant dans notre processus de développement, nous devons choisir celui à utiliser en fonction de notre situation réelle.
Par exemple, si le projet référencé A est fréquemment modifié au cours du processus de développement, nous vous recommandons d'utiliser la référence de projet. Parce que si vous utilisez nuget, vous devez reconstruire le projet référencé, recréer le package nuget, réinstaller ce package nuget dans le projet B, même vous devez le publier sur le serveur. Cela apportera beaucoup de travail inutile et nous oublions souvent de mettre à jour notre paquet nuget après avoir modifié le projet référencé A. Si vous utilisez la référence du projet, vous n'aurez pas ces problèmes. Le projet référencé A modifié sera mis à jour automatiquement avant de construire le projet B.
D'un autre côté, lorsque nous partageons notre projet référencé A hors solution, ou partageons ce projet avec d'autres, nuget sera un meilleur choix. Il a plus de portabilité.
Ainsi, la référence de projet sera recommandée lorsque vous faites référence à un autre projet A du projet B dans la même solution, le nuget est plus approprié lorsque vous partagez le projet de référence hors de la solution ou partagez le projet avec d'autres.
En outre, il existe une extension Visual Studio NuGet Reference Switcher , qui bascule automatiquement les références d'assemblage NuGet en références de projet et vice-versa.
J'espère que cela t'aides.
De nos jours, avec le nouveau format csproj, vous pouvez utiliser les deux en même temps (si vous avez les deux projets dans la même solution).
Dans votre exemple, vous pouvez référencer project A de project B comme référence de projet. Ensuite, si vous souhaitez libérer project A en tant que package NuGet, il vous suffit d'ajouter la balise suivante à son csproj dans un PropertyGroup:
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
La torsion de l'intrigue: Si vous voulez libérer project B en tant que package NuGet, ajoutez simplement la cible GeneratePackageOnBuild - MSBuild définira projectA.nupkg comme dépendance dans projectB.nupkg.
De cette façon, vous pouvez travailler en interne avec vos projets tout en les publiant sous forme de packages à des tiers ou à d'autres équipes.