NuGet packages referenced via PackageReference don't include DLLs in VSIX

[AlexEyler]

Summary

When building a VSIX that references NuGet packages, users used to be able to easily include the assembly included in the NuGet packages by setting to true on the reference. The VSSDK build tasks search through the @(ReferencePath) item for any reference that has CopyLocal set to true and then includes
those references in the VSIX.

PackageReferences don't give the option to the user to set CopyLocal to true, so it's difficult for the average user to get a NuGet reference included in a VSIX.

I've attached a binary log from a build of a VSIX that's created via the repro steps. Let me know if you need any info - we're willing to make changes in the VSSDK to support this if need be (as long as the changes are backwards compatible, of course).
msbuild.zip

Repro steps

1. Create a new VSIXProject
2. Make sure "PackageReference" is enabled by default by selecting Tools > NuGet Package Manager > Package Manager Settings.. and setting "Default package management format" to "PackageReference".
3. Right click on the VSIXProject and select "Manage NuGet packages"
4. Add a NuGet package that has a DLL (e.g. NuGet.VisualStudio).
5. Build the VSIXProject.
   Expected: NuGet.VisualStudio.dll is included in the VSIX.
   Actual: The VSIX does not contain NuGet.VisualStudio.dll.

Workaround

A workaround is available for VSIX developers:

<Target Name="IncludePackageReferenceDependencies" AfterTargets="GetVsixSourceItems">
  <ItemGroup>
    <VSIXSourceItem Include="@(ReferencePath)" Condition="$([System.String]::new('%(ReferencePath.FusionName)').StartsWith('NuGet.VisualStudio'))" />
  </ItemGroup>
</Target>

[rohit21agrawal]

I talked to alex offline about this, and it seems that the VS SDK needs to also start looking at ReferenceCopyLocalPaths item groups (which is also the item group that the target _CopyFilesMarkedCopyLocal used to copy these references the output directory) . The items won't have CopyLocal set to true (for some reason I can't understand) but as the name suggests , anything in ReferenceCopyLocalPaths is meant to be treated as CopyLocal= true.

The VS SDK would be a better place for this fix.

[rohit21agrawal]

Tracking bug for DevDiv internal bug #453911
update (via rob): ( currently milestone = 15.6)

[smourier]

FYI, I'm facing the same issue (I don't quite understand if it's supposed to be solved as of today), and I used another workaround (the one posted above included ref assemblies, not the real meat, at least for me). I'm running VS 15.5.4, for example:

<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>

[AlexEyler]

Thanks @smourier. This isn't fixed yet, but it's on the backlog. That workaround looks appropriate.

The workaround is NOT appropriate. For even the simplest VSIX project, there are over thirty packages that are pulled in. You can not expect developers to manage that in the .CSPROJ file manually as a workaround.

This issue has nothing to do with packages.config (PC) to PackageReference (PR) Migration. You can reproduce the problem using a package.config as well. VSIX just seems to be brain damaged when trying to use NuGet packages.

[UlyssesWu]

I'm still facing this issue in VS15.7.3. Can't believe it exists for such a long time.

BTW, the workaround @smourier provided works. I just saw @Dark-Bond 's answer on stackoverflow and you warned @smourier 's answer is invalid. But you have misunderstood the "VS15" is actually VS2017 rather than VS2015.