Should CoreCompile consume the ReferenceDependencyPaths item?

[rainersigwald]

More context is available at dotnet/msbuild#1520 (comment).

MSBuild's standard ResolveAssemblyReferences target emits a ReferencePath item containing references, and additionally emits a ReferenceDependencyPaths item containing the facade assemblies needed for the current framework target. Other compile-like steps use ReferenceDependencyPaths but CoreCompile does not.

Instead, the NETFramework.targets includes an ImplicitlyExpandDesignTimeFacades target that includes all assemblies from the facades directory into ReferencePath as a post-processing step.

Is this intentional, or an accident of history? It seems like we could eliminate ImplicitlyExpandDesignTimeFacades if CoreCompile consumed this additional item as references.

/cc @ericstj @cdmihai

[ericstj]

New piece of data I happened upon today.

ReferenceDependencyPaths is returned as part of BuiltProjectOutputGroupDependency, which is used by both Web Projects and ClickOnce packaging to mean "files that the app wants to copy along side it". This seems inconsistent with usage, since ReferenceCopyLocalPaths is actually what gets copied next to the app.

Any chance you guys can dig up an initial spec on this stuff?