如何在VSIX安装程序中包含NuGet包的程序集？

Question

我正在创建一个Visual Studio 2017自定义签入策略扩展.我目前的解决方案结构如下:

注意:我正在利用新的NuGet PackageReference方法,这就是没有packages.config文件的原因.

---

我相信我已经适当地设置了我的VSIX清单,因为当我没有引用时一切都很完美Microsoft.Net.Http(最初我是在值中硬编码而不是检索值).我不确定为什么Microsoft.TeamFoundationServer.ExtendedClient包含的NuGet包不会引起任何问题,而Microsoft.Net.HttpNuGet包也是如此.

我查看了调试文件夹以查看正在编译的内容,并且我看到每个程序集都被拉入,但是如果我解压缩VSIX(我将其重命名为*.zip并解压缩它),则只包含项目程序集; Nuget引用的程序集未打包在VSIX包中.

我遇到了一些资源,但似乎没有任何工作:

• VSIX包不包含引用项目的依赖项
• VSIX与项目模板和NuGet包
• 如何在Visual Studio扩展(vsix)中包含Nuget包
• VSIX扩展 - 如何确保VSIX文件中包含引用的dll或程序集？

这些问题/答案中的每一个似乎都没有解决我的具体问题.

---

更新:

我相信用于生成VSIX包的工具可能不支持PackageReferenceNuGet 的新功能.如果我使用旧的packages.config功能,一切正常.我已经放入了UserVoice Ticket来支持新的NuGet功能.

Answer 1

对于像我们这样面临这个问题的可怜人（使用 PackageReference 和 VSIX 依赖项的 nuget），我找到了一种解决方法，受到这篇文章的启发：NuGet packages referenced via PackageReference do not include DLLs in VSIX that did not full work for me (它包括程序集的仅元数据版本，而不是带有代码的完整程序集）。例如，这里我手动引用了4个nuget包：

<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：使用 Visual Studio 2017 从 15.5.4 到 15.7.3 进行测试

Answer 2

通过执行以下 Microsoft 教程中概述的步骤，我能够成功地将 NuGet 包包含在模板中：Visual Studio 模板中的包

使用 MSI 安装的 SDK 可以直接在开发人员的计算机上安装 NuGet 包。这使得它们在使用项目或项模板时立即可用，而不必在此期间提取它们。ASP.NET 模板使用这种方法。

我见过其他人因为他们使用的 NuGet 包而遇到问题。对于 .NET Core，我使用了Microsoft.Net.Http，尽管它确实需要Microsoft.BCL。除非您遇到问题，否则我建议按原样保留遗留系统，特别是因为这些命名空间似乎正在移动目标。

看来System.Net.Http是正确的选择，至少对于 Windows 平台上的 .NET 来说是这样。该软件包没有外部依赖项，这一点也毫无价值。

编辑： 看来这可能与PackageReference自身的错误有关。我看到这里描述了一个类似的记录错误。