Deployment Projects don't take architecture into account

[MattGal]

This isn't causing trouble right now, but was something I noticed in the course of other investigations. On a machine building multiple different verticals without cleaning, this could cause clashes / mismatches.

If you review a build log where this happens, you see stuff like:
E:\A\_work\89\s\corefx\packages\runtime.win7-x86.Microsoft.NETCore.Runtime.CoreCLR\2.0.0-beta-25021-03\runtimes\win7-x86\native\sos.dll (runtime.win7-x86.Microsoft.NETCore.Runtime.CoreCLR.2.0.0-beta-25021-03) -> E:\A\_work\89\s\corefx\bin\Windows_NT.AnyCPU.Debug\runtime\netcoreapp\sos.dll

but, we use the same output path for x64 as well. It would be useful for this to take into consideration the Arch of what's being copied when generating layouts like this.

[weshaggard]

@ericstj looks like something we might still need to consider cleaning up.

[ericstj]

Yeah, this is a generic problem when using configuration. I'd prefer we don't use outdir at all for these, nor try to build them incrementally. We should always be doing the up-to-date check between source dir from package and bin-placed location.

[ViktorHofer]

@ericstj your domain, I assume this is about depprojs? If yes then I think we can close this.

[ericstj]

The problem here is that runtime.depproj copies architecture specific bits, but it's outdir does not include architecture. I looked at a binlog for this project and it seems OutDir is the only Copy destination that doesn't have arch. We should either add Arch to the out and intermediate dirs for runtime.depproj or just disable copying to outdir.

Better yet if we can just delete runtime.depproj and have the coreclr subset copy things to the paths we expect in libraries.