This should either be defined globally or not at all.  Repeating all the logic on a local level is just wasted time.

TLDR: artifacts are going to move around in Binaries\Debug and the directory is going to get a lot bigger.

At a high level build projects can be classified into three categories based on how they write output:

- incorrect: a given output path is written to more than once with different contents
- less correct: a given output path is written to more than once but always with the same content
- correct: a given output path is written to exactly once

Today the roslyn build is decidedly “incorrect” as pretty much every file is written directly into Binaries\Debug. This means it ends up writing pretty much every Visual Studio SDK DLL twice: once for Dev14 and once for Dev15. For example at various points in the build Binaries\Debug\Microsoft.VisualStudio.Text.Data.dll may refer to Dev14 and at others it’s Dev15. If this seems like a scary proposition for a build that’s because it is indeed scary and it has real consequences. By now pretty much everyone on the team has hit the build race condition that is dragging down our PRs.

The general fix here is to move build outputs into separate directories. Instead of building to $(Configuration) projects now build into say $(Configuration)\Exes\$(MSBuildProjectFileName). This will have a substantial increase in the size of Binaries. We will be looking into ways to reduce that. In the short term though build stability far outweighs the size increase.

This change takes us most of the way to "correct". There are several places I had to compromise in order to get this initial change in:

- UnitTests still build to a common output folder (one for Dev14, another for Dev15). Pulling unit tests apart is going to take a bit of work.
- Every project has a <RoslynProjectType> entry. This will go away in the future for most projects. It's temporarily needed so I can fix roslyn-internal in parallel without taking down the build.
- VSL.Imports.targets is messy. Unavoidable for now due to the above. It will get cleaner as I iterate on this.

None of these are relevant to the underlying race condition. Hence it's okay to push them off.

The ImportGroup element is just noise.  It was also used very inconsistently in the repo and often within the same project file.  Just remove it.

The dependency projects serve a few purposes:

- Help ensure package unity by serving as a single place for a NuGet reference.
- Make NuGet updates simple by having a single place to change.
- Grouping together related packages to make it easy to take a dependency on say Visual Studio editor.

The first two points are largely obsolete now that our project.json references are strictly validated on every build and have a single update mechanism.  This meant a lot of our depnedency projects were just making Roslyn.sln bigger.

As such I went through and deleted all of them which had only 1 or 2 project.json entries.  I left the VS ones which tend to group 10+ references together.  They are still serving a valid "reference VS" purpose.

Samples.sln and Roslyn.sln were fighting over the GUIDs of Immutable, Metadata and Compostion.
Searching across the tree, and made sure that they were the uniform everywhere to prevent this.

This reverts commit 31377ce7.

Update TargetFrameworkVersions.

Updating System.Reflection.Metadata to 1.1.0-alpha-0015 and System.Collections.Immutable to 1.1.37.0

The targets files were previously split into an open version in
Microsoft.CodeAnalysis.Toolset.Open and a closed version in build/. This
unifies the four targets into two new targets, VSL.Settings.targets and
VSL.Imports.targets, and moves all the targets from ..Toolset.Open into
the build/ folder.

Upgrades System.Collections.Immutable to 1.1.34-rc and
System.Reflection.Metadata to 1.0.19-rc.

This reverts commit b37052d0.

     Background:

     As discussed in the dev team all hands all code under the GitHub dotnet foundation is using a single process for contribution, API review, infrastructure and coding style. The idea is to present a unified view to our customer and give them a single story for contributing to any project under the dotnet foundation.

     https://github.com/dotnet/corefx/wiki/Contributing#c-coding-style

     The coding style transition is automated using a Roslyn based rewrite tool:

     https://github.com/dotnet/codeformatter

     This will be applied in stages across our developer tree. Right now the focus is on the Open directory as this is what is being presented on github. Code owners will be contacted before the transition happens.

     Note: this is a soft style requirement. There are no build errors that come from this change.
 (changeset 1408227)

This moves our settings / targets files into the Open directory.  These files are a referenced by virtually all of the projects in the Open directory and are a necessary part of the build process.  Making this change is a necessary step in removing the project scrubber.  (changeset 1396832)

This changeset introduces the concept of a "global" nuget package. The references to the NuGet packages are inserted into the Open VSL.Settings.targets file, which is imported into every project in Roslyn. This ensures that every project automatically gets these "global" packages. (changeset 1386548)

Updates System.Collections.Immutable and System.Metadata.Reader to versions 1.1.33-beta and 1.0.18-beta, respectively.
     Updates VSMEF to the latest build from VSPRO_1.

     A few code fixes:
     - ImmutableArrayInterop is gone
       - in product we used in a couple of places where we now just create a copy of the byte[] (MetadataWriter)
       - test infrastructure uses a workaround with explicitly laid out union to avoid copies of large metadata blobs
     - EditorTestApp class was incorrectly importing MEF components resulting in a cycle. The new VSMEF reports such errors. (changeset 1385613)

Add full NuGet package restore to Test.cmd and fix Open samples to direct packages up to the solution packages directory. (changeset 1359108)

***NO_CI***
 (changeset 1357023)

***NO_CI***
 (changeset 1356181)

This also updates Microsoft.Net.ToolsetCompiler to the corresponding version. (changeset 1355122)

This change splits the Workspaces layer into two parts, mirroring the Portable/Desktop split that the compilers did. The core parts of the Workspaces layer (managing documents and projects, formatting, some refactoring, code fixes) is kept in the portable subset, with a few non-portable pieces remaining, notably MSBuild support.

This change has a major impact on how MEF now works in Roslyn. Traditional MEF (“MEFv1”) is not portable, and so we must move the Workspaces layer over to using the Microsoft.Composition NuGet package (“MEFv2”) which is. The APIs are distinct in that each has its own namespace, but the concepts are more or less identical. It requires some care though: the workspaces layer is simple in that it only references MEFv2, but higher layers have to reference both versions to use metadata attributes. Exports using metadata attributes from the editor (say, ContentTypeAttribute) must use MEFv1 attributes to export, whereas exports for the workspaces layer must use MEFv2 attributes. The rule is subtle and yet simple, and so a diagnostic is provided which catches any offenses to prevent confusion.

This also has some impact in how we create MEF hosts: if you wish to host just the base workspaces layer, we can use MEFv2 to compose everything. The HostServices implementation (MefV1HostServices) that consumes a MEFv1 ExportProvider. If you’re in Visual Studio, you can use this implementation to get the full set of host services provided in Visual Studio.

Otherwise, most of the changes in here are minor: we react to some APIs that have been moved/renamed in the portable subset we are targeting, and also align our various exception helper utilities with the compiler’s precedent. (changeset 1349276)

***NO_CI***
 (changeset 1341082)