Comment inclure des assemblages de paquets NuGet dans un programme d'installation VSIX?

Je travaille à la création d'une extension de politique d'enregistrement personnalisée Visual Studio 2017. Ma solution actuelle est structurée comme suit:Comment inclure des assemblages de paquets NuGet dans un programme d'installation VSIX?

Note: Je profite de la nouvelle approche NuGet PackageReference, ce qui est la raison pour laquelle il n'y a pas de fichier packages.config.

Je crois que j'ai installé mon VSIX manifestent depuis tout fonctionne correctement parfaitement quand je ne fait pas référence à Microsoft.Net.Http (à l'origine j'étais coder en dur des valeurs au lieu de récupérer les valeurs). Je ne sais pas pourquoi le paquet NuGet Microsoft.TeamFoundationServer.ExtendedClient inclus ne cause aucun problème, alors que le paquet NuGet Microsoft.Net.Http le fait. J'ai regardé le dossier de débogage pour voir ce qui est en train d'être compilé et je vois chaque assemblage nécessaire, mais si je décompose le VSIX (je l'ai renommé en .zip et l'ai décompressé), seul l'assemblage du projet est inclus; les assemblys référencés par Nuget ne sont pas empaquetés dans le package VSIX.

je suis tombé sur quelques ressources, mais rien ne semble fonctionner:

Chacun de ces questions/réponses ne semble pas aborder mon problème spécifique.

Mise à jour:

Je crois qu'il est possible que l'outil utilisé pour générer le package VSIX ne prend pas en charge la nouvelle fonctionnalité de PackageReference NuGet. Si j'utilise l'ancienne fonctionnalité packages.config, tout fonctionne correctement. J'ai mis dans un UserVoice Ticket pour soutenir la nouvelle fonctionnalité de NuGet.

Source

2017-05-01 m-y

je pourrais arriver en retard, mais ce fil résolu mon problème: https: // stackoverflow. com/questions/42201923/vsix-extension-comment-peut-je-assurer-une-référence-dll-ou-assemblage-est-inclus-dans-e –

@ AmauryLevé: Cette question peut avoir résolu votre problème, mais il est complètement sans rapport avec le problème que je référence, qui avait à voir avec le conditionneur VSIX inclure automatiquement des assemblées grâce à la fonctionnalité PackageReference de NuGet. Cette question/réponse traite de l'ajout d'actifs en référençant les assemblées directement. –

j'ai pu inclure avec succès des paquets NuGet dans un modèle en effectuant les étapes décrites dans le tutoriel Microsoft suivant: Packages in Visual Studio templates

SDKs qui sont installés à l'aide d'un MSI peut installer des paquets NuGet directement sur la machine du développeur. Cela les rend immédiatement disponibles lorsqu'un modèle de projet ou d'élément est utilisé, plutôt que d'avoir à les extraire pendant ce temps. Les modèles ASP.NET utilisent cette approche.

J'ai vu d'autres personnes rencontrant des problèmes à cause des paquets NuGet qu'elles utilisent. Pour .NET Core, j'ai utilisé Microsoft.Net.Http, bien qu'il nécessite Microsoft.BCL. Sauf si vous rencontrez des problèmes, je suggère de laisser les systèmes existants tels quels, d'autant plus que ces espaces de noms semblent être des cibles mobiles.

Il semble System.Net.Http est le bon choix, au moins pour .NET sur la plate-forme Windows. Cela ne vaut rien non plus que ce paquet n'ait pas de dépendances externes.

EDIT: Il semble que cela pourrait être lié à des bugs avec PackageReference lui-même. Je vois un bug documenté similaire décrit here.

Source

2017-05-26 14:34:32 lax1089

Je pense que vous avez mal compris le problème que j'ai. Je ne crée pas de modèles d'élément ou de projet, mais plutôt une règle d'archivage personnalisée. Le problème que j'ai rencontré est que le paquetage VSIX généré n'incluait pas les assemblages NuGet dont mon assembly dépendait. Le lien auquel vous faites référence consiste à vérifier que les modèles d'élément/projet tirent automatiquement les packages NuGet dans le projet qui utilise ces modèles. En outre, le problème concerne la nouvelle fonctionnalité PackageReference de NuGet. Tout fonctionne très bien si j'utilise la méthode packages.config de NuGet à la place –

Juste par curiosité, y a-t-il une raison pour laquelle vous voulez/devez utiliser la fonctionnalité PackageReference de NuGet? – lax1089

Oui, http://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html - fondamentalement, il a beaucoup d'avantages et représente l'avenir de NuGet. –

Pour les pauvres gars comme nous qui rencontrons ce problème (la combinaison nuget + vsix + netstandard + vs est plus meurtrière tous les jours), j'ai trouvé une solution de contournement, inspirée par ce post: NuGet packages referenced via PackageReference don't include DLLs in VSIX. Par exemple, ici, je fais référence 4 paquets NuGet manuellement:

<Target Name="IncludeNuGetPackageReferences" AfterTargets="GetVsixSourceItems"> 
    <ItemGroup> 
    <VSIXSourceItem Include="@(ReferenceCopyLocalPaths)" Condition="'%(ReferenceCopyLocalPaths.NuGetPackageId)' == 'Microsoft.Win32.Registry'" /> 
    <VSIXSourceItem Include="@(ReferenceCopyLocalPaths)" Condition="'%(ReferenceCopyLocalPaths.NuGetPackageId)' == 'System.CodeDom'" /> 
    <VSIXSourceItem Include="@(ReferenceCopyLocalPaths)" Condition="'%(ReferenceCopyLocalPaths.NuGetPackageId)' == 'System.Configuration.ConfigurationManager'" /> 
    <VSIXSourceItem Include="@(ReferenceCopyLocalPaths)" Condition="'%(ReferenceCopyLocalPaths.NuGetPackageId)' == 'System.ServiceProcess.ServiceController'" /> 
    </ItemGroup> 
</Target>

PS: Je suis en cours d'exécution Visual Studio 15.5.4

Source

2018-01-19 14:10:08

Comment inclure des assemblages de paquets NuGet dans un programme d'installation VSIX?

Répondre

Questions connexes