Satellite assemblies from PackageReference all copy to root bin folder

From @AArnott on June 20, 2017 15:19

Details about Problem

NuGet product used (NuGet.exe | VS UI | Package Manager Console | dotnet.exe): 4.3.0

VS version (if appropriate): 15.3.26616.2.d15rel

OS version (i.e. win10 v1607 (14393.321)): Win10 15063.rs2_release.170317-1834

Worked before? If so, with which NuGet version: Yes, this worked in 15.1 or 15.2 I believe.

Detailed repro steps so we can see the same problem

Create a new .NET Core library, then replace the project file content with this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net46</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.VisualStudio.Composition" Version="15.0.71" />
  </ItemGroup>
</Project>

Restore, and build.

Expected

The project’s bin folder has just a few DLLs, and a bunch of culture folders, each with a few *.resources.dll assemblies.

Actual

The bin folder that contains the project output no sub-folders. Instead, “all” the satellite assemblies are copied into that one root bin folder, causing each one to overwrite another so that only one culture wins. And at runtime, the satellite assemblies cannot be found.

Copied from original issue: NuGet/Home#5458

[nguerrera]

Here is a workaround when using v2.0 is not possible:

  <!-- Work around bug in Microsoft.NET.Sdk < v2.0 where satellites were deployed on top of each other in root. -->
  <!-- https://github.com/dotnet/sdk/issues/1360 -->
  <Target Name="WorkaroundIncorrectSatelliteDeployment" AfterTargets="ResolveLockFileCopyLocalProjectDeps">
    <ItemGroup>
      <ReferenceCopyLocalPaths Remove="@(ResourceCopyLocalItems)" />
      <ReferenceCopyLocalPaths Include="@(ResourceCopyLocalItems)" Condition="'@(ResourceCopyLocalItems)' != ''">
        <DestinationSubDirectory>$([System.IO.Directory]::GetParent(%(ResourceCopyLocalItems.FullPath)).get_Name())\</DestinationSubDirectory>
      </ReferenceCopyLocalPaths>
    </ItemGroup>
  </Target>

[jaredpar]

@nguerrera verified this works. Our build correctness leg is no longer flagging double writes and I manually verified the output directory contains the proper resource layout. Thanks!