Как включить сборки из пакетов NuGet в установщик VSIX?

Я работаю над созданием специального расширения политики проверки Visual Studio 2017. Мое текущее решение структурировано следующим образом:

Примечание. Я использую новый подход NuGet PackageReference, поэтому файл pack.config отсутствует.

Я считаю, что я правильно настроил свой VSIX-манифест, так как все работает отлично, когда я не ссылаюсь на Microsoft.Net.Http (изначально я был жестко кодирован в значениях вместо того, чтобы извлекать значения). Я не уверен, почему пакет Microsoft.TeamFoundationServer.ExtendedClient NuGet, который включен, не вызывает никаких проблем, тогда как пакет Microsoft.Net.Http NuGet делает.

Я просмотрел папку отладки, чтобы увидеть, что компилируется, и я вижу, что каждая сборка необходима, но если я распакую VSIX (я переименовал ее в .zip и распаковал ее), включена только сборка проекта; Nuget, на которые ссылаются сборки, не упакованы в пакет VSIX.

Я наткнулся на несколько ресурсов, но ничего не работает:

Кажется, что каждый из этих вопросов/ответов не затрагивает мою конкретную проблему.

Update:

Я считаю, что возможно, что инструмент, используемый для создания пакета VSIX, не поддерживает новую функцию PackageReference NuGet. Если я использую более старую функцию package.config, все работает нормально. Я добавил UserVoice Ticket для поддержки новой функции NuGet.

Ответ 1

Мне удалось успешно включить пакеты NuGet в шаблон, выполнив шаги, описанные в следующем учебнике Microsoft: Пакеты в шаблонах Visual Studio

SDK, установленные с помощью MSI, могут устанавливать пакеты NuGet непосредственно на машине разработчика. Это делает их сразу доступными, когда используется шаблон проекта или элемента, вместо того, чтобы извлекать их в течение этого времени. Шаблоны ASP.NET используют этот подход.

Я видел, как другие испытывают проблемы из-за пакетов NuGet, которые они используют. Для .NET Core я использовал Microsoft.Net.Http, хотя для этого требуется Microsoft.BCL. Если у вас нет проблем, я предлагаю оставить устаревшие системы как есть, тем более, что эти пространства имен, похоже, движутся цели.

Появляется System.Net.Http - правильный выбор, по крайней мере для .NET на платформе Windows. Также не стоит ничего, что этот пакет не имеет внешних зависимостей.

EDIT: Похоже, это может быть связано с ошибками с PackageReference. Я вижу подобную документированную ошибку, описанную здесь здесь.

Ответ 2

Для тех бедных парней, как мы, кто сталкивается с этой проблемой (nuget + vsix + netstandard + vs сочетается с каждым днем), я нашел обходное решение, вдохновленное этим сообщением: Пакеты NuGet, на которые ссылаются через PackageReference, не включают библиотеки DLL в VSIX. Например, здесь я ссылаюсь на 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 15.5.4