Sdk: csproj class libraries don't copy resource dll's to parent projects output folder

[TheRealPiotrP]

Moving from https://github.com/dotnet/cli/issues/4153 on behalf @ryanbrandenburg.

---

This is a continuation of aspnet/Home#1707 with a little more information after investigation.

Steps to reproduce

1. Build the app from the zip in aspnet/Home#1707.
2. Run the Console Application and verify that it will iterate through the supported cultures and print out "Hello World" in that culture.
3. Run the Web App and land on the home page. You should see "Hello World" in the culture specified in the request by the browser or the culture specified in the query string. Instead you will always see "Hello World". There are links on the home page that allow the user to reload the page in one of the supported languages by adding it to the query string. They will all show "Hello World" even though it is clear that the current culture info has changed on the executing thread.
4. Copy the language folders from the console application into the appropriate location in the web application and reload the page, observing that the non-base localization now works.

This appears to work fine if you create an equivalent class library using project.json.

Expected behavior

Old style class libraries should copy their resource dll's to the appropriate location, allowing them to localize.

Actual behavior

The resources are not copied, and therefor cannot be used in localization.

Environment data

dotnet --info output:
.NET Command Line Tools (1.0.0-preview2-003121)

Product Information:
Version: 1.0.0-preview2-003121
Commit SHA-1 hash: 1e9d529bc5

Runtime Environment:
OS Name: Windows
OS Version: 10.0.10586
OS Platform: Windows
RID: win10-x64

[DanielLaberge]

This is quite problematic for us. Any known workaround other than manually copying the files?

We'll be using a build event to copy the files, but it seems like quite a hack given that the target folder _(\bin\Debug\net46\win7-x64)_ can change from one environment to another.

[nguerrera]

I cannot reproduce this with the zip provided. It is using the old project.json, but after migration I see the satellites in the output folder as expected and F5 on my French machine gives this:

[nguerrera]

It seems the original issue was when wrapping a classic .csproj with satellite assemblies into a project.json consumable asset. This is not an issue with everything migrated over to .csproj using Visual Studio 2017 RC and CLI preview3 or newer. There is nothing that I can see that needs changing in the SDK.

[DanielLaberge]

So this will not get fixed for VS2015, correct?

[ripenko]

Does anybody can describe the workaround? Should I open the project with 2017 RC? Or what?

[nguerrera]

Should I open the project with 2017 RC?

@AlexeyRipenko Yes

[ripenko]

thanks. Will be fixed it for VS 2015? If not than should I recommend my clients to do not use VS 2015 for ASP.NET Core projects?