J'ai une solution Visual Studio avec deux projets - une bibliothèque .NET Standard (2.0) contenant une certaine logique et une bibliothèque de classes .NET Framework (4.6.1) contenant une interface utilisateur, etc. La bibliothèque .NET Framework a alors l'extension. NET Standard a été ajoutée comme référence de projet afin de pouvoir utiliser les méthodes contenues dans la bibliothèque logique.
J'utilise ensuite Azure Pipelines dans Azure DevOps pour créer ces deux projets, les emballer en tant que packages NuGet et les pousser vers un serveur NuGet fourni par Azure Devops (Azure Artifacts).
Cependant, lorsque les packages NuGet sont publiés, ils incluent uniquement les dépendances dans NuGet sur les packages que j'ai ajoutés aux projets via NuGet. Ce que je veux idéalement, c'est lorsque ma bibliothèque .NET Standard (logique) est empaquetée et poussée vers le serveur NuGet, une référence à celle-ci sur NuGet (avec le numéro de version mis à jour, etc.) est ajoutée à ma bibliothèque .NET Framework (UI).
Quelqu'un d'autre a-t-il eu ce problème qui pourrait me donner des conseils sur la façon de le résoudre s'il vous plaît? J'ai jeté un coup d'œil en ligne et j'ai dessiné un blanc jusqu'à présent.
Merci!
5 Réponses :
NuGet CLI rencontre des problèmes avec les dépendances pour les références de package et les références de projet (uniquement lorsque le est un .net Core ou .net Standard aussi?) lorsque vous n'utilisez pas Fichiers .nuspec .
Utilisez dotnet pack ou msbuild -t: pack pour inclure la référence du projet en tant que dépendance nuget. Cela résout également les problèmes de PackageReferences qui ne sont pas écrits en tant que dépendances.
En supposant que votre projet de framework .net soit prêt à l'emploi de Visual Studio, vous devrez référencer le Nuget.Build .Tasks.Pack nuget package pour accéder aux cibles nécessaires. Nous écrivons ces données dans le fichier .csproj avec PowerShell sur le serveur de construction avant toute restauration de nuget afin que cela ne soit pas oublié pour les nouveaux projets de cadre complet (que nous essayons d'éviter de créer). Comme @zivkan l'a mentionné, vous voudrez probablement
définissez PrivateAssets sur all pour éviter que ce paquet ne devienne une dépendance nuget
<PackageReference Include="NuGet.Build.Tasks.Pack"> <PrivateAssets>all</PrivateAssets> <Version>4.8.0</Version> </PackageReference>
Modification d'une référence de projet à une référence de package NuGet lors de la construction
J'ai peur que vous n'ayez pas pu convertir la référence du projet en référence du package nuget pendant la construction. Cela parce que ce sont deux manières différentes de traiter les références. Bien qu'il existe maintenant des extensions qui peuvent convertir une référence de projet en référence de package nuget, elles nécessitent une opération manuelle, nous n'avons pas pu l'utiliser pendant la construction.
Consultez l ' un autre fil de discussion pour plus de détails.
Nous n'avons donc pas pu changer la référence de projet bibliothèque .NET Standard (2.0) en référence de package NuGet et l'ajouter à votre bibliothèque .NET Framework (UI) sur build .
Personnellement, pour résoudre ce problème, vous pouvez utiliser la référence au projet .net Standard (.netSrd) comme référence de package nuget sur votre local, lorsque vous avez mis à jour le package nuget de numéro de version pour le projet .net Standard, vous pouvez mettre à jour ce package dans vos artefacts Azure et utilisez la commande de tâche nuget personnalisée pour appeler nuget update pour mettre à jour les packages vers la dernière version lorsque vous créez votre bibliothèque .NET Framework (UI).
Vérifiez les informations détaillées de:
Mettez à jour le package NuGet vers la dernière version après construire en VSTS
J'espère que cela vous aidera.
Il est tout à fait possible «d'échanger» la référence de projet contre une référence de package si l'on souhaite apporter ces modifications au fichier .csproj avant d'effectuer une restauration et une compilation NuGet.
Ma réponse comprend deux parties.
Premièrement, si vous utilisez dotnet pack ou msbuild -t: pack , sans fichier nuspec, alors les références de projet deviennent automatiquement des dépendances nuget. J'ai vérifié cela à l'aide des commandes suivantes:
dotnet new classlib -n ProjectA dotnet new classlib -n ProjectB dotnet add ProjectB/ProjectB.csproj reference ProjectA/ProjectA.csproj dotnet pack ProjectB/ProjectB.csproj
ProjectB.1.0.0.nupkg a une dépendance nuget sur ProjectA v1.0.0 . Cela fonctionne «prêt à l'emploi» avec les projets de style SDK, mais si vous avez un projet de «style ancien» (qui importe Microsoft.CSharp.targets), vous devrez ajouter une référence de package à NuGet.Build.Tasks.Pack . Si vous utilisez PackageReference, vous devrez peut-être modifier votre csproj et définir cette dépendance pour définir PrivateAssets sur all pour éviter que ce package ne devienne une dépendance nuget. Je ne sais pas quel est l'équivalent si vous utilisez packages.config, ou si c'est même possible. Si vous utilisez msbuild ou dotnet pack, mais que vous avez également votre propre fichier nuspec, je vous le déconseille. Tout ce que vous voulez faire dans le nuspec devrait être possible en définissant les bonnes propriétés ou les bons attributs d'élément dans votre csproj, et laissez les cibles du pack générer automatiquement le nuspec. Lorsque vous avez votre propre nuspec, certaines parties de la génération automatique de nuget sont désactivées, vous vous compliquez peut-être les choses.
Ma mémoire de nuget pack sur l'ancien style csproj fichiers est que nuget fera automatiquement d'une référence de projet une dépendance de nuget tant que le projet référencé a un fichier dans le même répertoire que le (je suis presque certain qu'il est documenté quelque part sur docs.microsoft.com/nuget). Cependant, si votre projet dépendant est un projet de style SDK (comme c'est nécessaire pour les projets .NET Core ou .NET Standard), alors j'ai déjà déconseillé d'utiliser un fichier nuspec avec ces projets, vous devriez donc vraiment envisager d'utiliser les cibles du pack et arrêter en utilisant nuget pack .
La deuxième partie de ma réponse répondra directement à votre question, qui est de savoir comment faire référence à un projet une référence de package sur certaines versions. Tout d'abord, vous devez utiliser des cibles de pack, soit en utilisant un projet de style SDK, soit en référençant le package NuGet.Build.Tasks.Pack. De cette façon, vous n'utilisez pas de fichier nuspec , et tout est défini dans votre csproj , qui est juste un fichier MSBuild. MSBuild a des conditions, donc éditez manuellement votre csproj et faites en sorte que la référence de votre projet ait une certaine condition et que la référence du package ait la condition opposée. Je suggère d'utiliser une variable comme $ (CI), afin que vous puissiez tester le pack en utilisant msbuild -t: pack -p: CI = true , et sur votre machine CI, définissez simplement CI comme variable d'environnement sur vrai. Étant donné que NuGet a déjà des fonctionnalités intégrées pour créer des références de projet dans des dépendances nuget, je recommande de l'utiliser et de ne pas basculer entre les références de package et de projet.Je ne vais donc pas donner un exemple de copier-coller sur la façon de procéder. Mais si ce n'est pas le cas d'un problème XY et que vous devez vraiment le faire , alors j'ai déjà donné suffisamment de pointeurs pour que vous puissiez comprendre comment faire le reste.
Si vous utilisez le nouveau format csproj (conçu pour .NET Core mais peut fonctionner avec n'importe quel .NET), c'est assez simple.
Dans les projets que vous souhaitez publier en tant que packages NuGet, vous devez ajouter le csproj ce qui suit:
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
En dehors de cela, vous n'avez qu'à référencer vos autres projets avec ProjectReferences. MSBuild construira tout, et lors de la publication des packages NuGet, il changera les ProjectReferences en PackageReferences.
Si vous avez un ProjectReference, il remplacera n'importe quel package références au même ID de package dans le graphique de restauration.
Source: Résoudre les références de packages aux projets (problème dotnet github)
J'ai essayé moi-même (j'ai ajouté à la fois le ProjectReference et le PackageReference dans le fichier csproj). Il se construit avec succès et le fichier NuGet de sortie contient la dépendance à l'autre package NuGet.
Pourriez-vous clarifier ce que vous entendez par "ils n'incluent que les dépendances dans NuGet sur les packages que j'ai ajoutés aux projets via NuGet"? Je ne vois pas ce que vous entendez par là. Je n'utilise pas Azure Pipelines, etc., mais le pack dotnet normal ajoute les dépendances pertinentes
Comment créez-vous le projet .net Framework? Utilisez-vous la tâche .NuGet Pack ou MSBuild -t: Pack?
D'après le titre de la question: réécrivez-vous actuellement votre netFW .csproj sur le serveur de build pour changer la référence de projet en référence de package, ou est-ce une idée de ce que vous voulez faire?
Si votre package .net Framework fait référence au projet .net Standard en tant que référence de projet, le binaire du projet .netSrd doit être inclus dans le répertoire
/ libde votre package .netFW.Utilisez les conditions MSBuild pour avoir deux références dans votre projet en même temps. La condition peut être un test par rapport à une variable d'environnement ou tout autre élément approprié. Ensuite, sur n'importe quelle machine, vous pouvez définir / réinitialiser la variable pour tester la compilation.
@JonSkeet Ce que j'entends par là, c'est que les packages NuGet que j'ai référencés dans la version locale de mon application sont ajoutés en tant que dépendances dans le package NuGet qui est créé (pour des éléments tels que Entity Framework Core, le pilote EF Core MySQL, AutoMapper, etc.).
@JoshGust J'emballe le projet .NET Framework en utilisant 'nuget pack'. Dans l'état actuel des choses, je ne fais rien sur le serveur de compilation pour changer la référence du projet en une référence de package - il semble d'après les réponses données jusqu'à présent que c'est la partie qui me manque.
@JoshGust J'ai également essayé d'utiliser le commutateur '-IncludeReferencedProjects' sur l'étape de construction 'nuget pack' de mon pipeline pour inclure la bibliothèque .NET Standard, mais j'obtiens le message d'erreur "Impossible de convertir l'objet de type 'System.String 'pour taper' NuGet.Frameworks.NuGet.Frameworks1069249.NuGetFramework '. " J'ai eu une erreur similaire en essayant d'emballer la bibliothèque .NET Standard en utilisant 'nuget pack' que j'ai résolu en utilisant 'dotnet pack' à la place. Il semble que la CLI Nuget "n'aime pas" les bibliothèques .NET Standard.
Ce que vous voulez arriver (si je comprends bien) est exactement ce qui se passe dans ma propre version. Cela vous aiderait si vous pouviez fournir un exemple minimal reproductible avec les deux projets - en partie pour que nous puissions savoir quel style de fichier de projet qu'ils sont. (Si vous utilisez un projet «ancien style» pour le projet .NET, essayez de le déplacer vers le projet «style SDK» - c'est peut-être tout ce que vous devez faire.)
@StevenDay Il semble que vous devriez utiliser
dotnet packoumsbuild -t: packavec un projet de "style SDK" ou une référence de package à Nuget.Build .Tasks.Pack pour le projet de framework .net, comme mentionné à la fois dans ma réponse et dans celle de @zivkan.@StevenDay ceci peut aider à expliquer l'erreur
impossible de diffuservous obtenez, et ceci m'a aidé à comprendre que le cli nuget a problèmes de création de références de dépendance lorsque vous n'utilisez pas de fichiers.nuspec.