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

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.

[DanielLaberge]

So this will not get fixed for VS2015, correct?