dotnet / msbuild

The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
https://docs.microsoft.com/visualstudio/msbuild/msbuild
MIT License
5.23k stars 1.35k forks source link

CopyLocal for satellite assemblies broken: copies all of them to the same bin directory #1994

Closed AArnott closed 7 years ago

AArnott commented 7 years ago

When copied locally to an app, satellite assemblies should always be copied to their respective subdirectories according to their culture.

When a project defines TargetFrameworks, this behavior regresses. It works fine when TargetFramework is defined directly in a project instead.

Repro steps

dotnet new classlib
dotnet add package microsoft.visualstudio.validation -v 15.0.82

Modify project file as follows:

 <Project Sdk="Microsoft.NET.Sdk">
   <PropertyGroup>
-    <TargetFramework>netstandard1.4</TargetFramework>
+    <TargetFrameworks>net46</TargetFrameworks>
   </PropertyGroup>
   <ItemGroup>
     <PackageReference Include="microsoft.visualstudio.validation" Version="15.0.82" />

Then restore and build:

dotnet restore
dotnet build

Expected

Satellite assemblies for the PackageReference to be copied to their appropriate subdirectories like this:

C:\TEMP\LOC2\BIN
└───Debug
    └───net46
        │   loc2.dll
        │   loc2.pdb
        │   Microsoft.VisualStudio.Validation.dll
        │
        ├───es
        │       Microsoft.VisualStudio.Validation.resources.dll
        │
        └───jp
                Microsoft.VisualStudio.Validation.resources.dll

Actual

The satellite assemblies are all copied to the root bin folder:

C:\TEMP\LOC2\BIN
└───Debug
    └───net46
            loc2.dll
            loc2.pdb
            Microsoft.VisualStudio.Validation.dll
            Microsoft.VisualStudio.Validation.resources.dll

This is a problem for several reasons:

  1. the app, and tests, will misbehave as they won't find the satellite resource assemblies at runtime.
  2. during the build, all the satellite assemblies are copied, such that the build log reveals we have multiple file writes to the same location. I presume the result is non-deterministic.

Note that dotnet publish -f net46 lays the files out in their correct locations. But this is not an acceptable workaround for local building and testing. This is a regression as NuGet references previous to VS2017 (15.1) would copy them to the right locations and I depend on that.

rainersigwald commented 7 years ago

This issue was moved to dotnet/sdk#1132