PackageReferences put ref instead of lib assemblies in the BuiltProjectOutputGroupDependencies output group used by VS installer projects

[MSLukeWest]

NuGet product used: VS UI

NuGet version: 5.6.0.6489

VS version (if appropriate): 16.5

OS version: 19h1

Worked before? If so, with which NuGet version: Never worked with PackageRef, still works with Package.json

Detailed repro steps so we can see the same problem

1. Create a .NET framework C# console app
2. Manage Nuget packages, add latest System.ValueTuple (4.5.0)
3. Right click on packages.config in SE, select "Migrate packages.config to PackageReference …" (Note: No repro if you use packages.config)
4. Add a setup project that references the primary output of the console app and build (Requires VS extension: https://marketplace.visualstudio.com/items?itemName=visualstudioclient.MicrosoftVisualStudio2017InstallerProjects)
5. Install the generated msi

Expected: It installs the System.ValueTuple assembly from the “lib” directory
Actual: It installs the assembly from the “ref” directory, causing runtime failures

The output group BuiltProjectOutputGroupDependencies is incorrectly populated when using a package reference to consume nuget packages that have both ref and lib versions of their assemblies. Some inital inspection of the build logs shows that with packages.config the lib version is added to the "Reference" item group, which eventually makes its way into a ReferencePath item, which gets added to BuiltProjectOutputGroupDependencies.

With PackageReference, ResolveNuGetPackageAssets adds:

• lib to ReferenceCopyLocalPaths
• ref to Reference

So even though the lib version makes it to the bin folder through ReferenceCopyLocalPaths, the ref version is what gets added to BuiltProjectOutputGroupDependencies.

This has been reported by a few different customers, here’s a link to one of the feedback tickets: https://developercommunity.visualstudio.com/content/problem/810090/visual-studio-installer-projects-extensions-incorr.html. As we mentioned in that ticket, there’s a couple potential workarounds, but neither of them are very reliable.

[yirkha]

FYI I think this is not an issue with NuGet but rather the Visual Studio Installer Extensions SDK.

Their MSBuild integration uses BuiltProjectOutputGroupDependencies in a way that should not be done – see this issue for details: dotnet/msbuild#3069

I've provided a workaround in Azure/azure-sdk-for-net#3699 (comment) which might potentially work similarly in this case too.

[MSLukeWest]

Thanks @yirkha. I'm adding the work around here for easier access. Putting this at the end of your csproj file will get around this issue when using installer projects (requires a restart of VS):

<Target
	Name="BuiltProjectOutputGroupDependencies"
	DependsOnTargets="$(BuiltProjectOutputGroupDependenciesDependsOn)"
	Returns="@(BuiltProjectOutputGroupDependency)">
	<ItemGroup>
		<BuiltProjectOutputGroupDependency Include="@(ReferenceCopyLocalPaths->'%(FullPath)');
                                              @(ReferenceDependencyPaths->'%(FullPath)');
                                              @(NativeReferenceFile->'%(FullPath)');
                                              @(_DeploymentLooseManifestFile->'%(FullPath)');
                                              @(ResolvedIsolatedComModules->'%(FullPath)')"/>
	</ItemGroup>
</Target>

[nkolev92]

Closing as per the previous comments.
This is not something in NuGet Client's control.

[xxl-cc]

i have same problem。

[mbihler]

Thanks @yirkha. Your workaround works with my setup project.
But because COM wrapper assemblies were missing in generated msi, I had to add this to the include list:
@(ReferenceComWrappersToCopyLocal->'%(FullPath)')