Satellite assemblies from PackageReference all copy to root bin folder

[AArnott]

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

[AArnott]

From @rohit21agrawal on June 20, 2017 18:36

shouldn't this go to msbuild?

[AArnott]

I expected NuGet owned the .targets that copy files from nuget packages into the user's bin folder based on PackageReference.

[AArnott]

From @rohit21agrawal on June 20, 2017 18:57

NuGet doesn't decide where the DLLs would be copied to on disk. It only creates an assets file which is a dependency graph, then NuGetBuildTasks convert these to References. Finally, SDK targets decide what to do with these references. So I would lean towards this being something that SDK isn't handling well.

[AArnott]

Very well. It only seems to repro for .NET SDK projects so I'll move to dotnet/sdk

[nguerrera]

This is the same as #1006 and #1132, fixed by #1224, but that fix is only in v2.0 of the SDK, which requires the v2.0 .NET Core SDK to be installed as it does not ship with Visual Studio 15.3 (only v1.1 does).

I'll be documenting a work-around here shortly for projects that must work on v1.1 too.

cc @jaredpar

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

[nguerrera]

Closing as duplicate since this is already fixed in latest bits.

[nguerrera]

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

This is not in fact a regression. 15.0, 15.1, 15.2 would have exhibited the same behavior for Microsoft.NET.Sdk-using project targeting net4x (where we copy-local of nuget dependencies is on by default).

[AArnott]

Thanks, @nguerrera

[AArnott]

@onovotny do you want to include this workaround in https://github.com/onovotny/MSBuildSdkExtras?

[clairernovotny]

@nguerrera I assume that workaround should be disabled with the 2.0 SDK so we don't interfere?

Would a check like this work to only apply to SDK's lower than 2.0? https://github.com/paulcbetts/refit/blob/master/Refit/targets/refit.targets#L15-L27

[AArnott]

@onovotny The myapps link you shared doesn't work for me.