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.

updated build and test to recognize Dev15Tests

re-arranged test export provider

This change drops support for .NET 4.5 and retargets to desktop
4.6 + CoreCLR. It also fixes up various analyzer warnings that
were created due to the move.

Fixes #12926

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.

This reverts commit 720f5c5e, reversing
changes made to 6a6043c3.

changes include
make SourceText::GetChecksum and AnalyzerTelemetry contructor public.

added MustRunInProc in IBuiltInAnalyzer and some clean up around serializing Solution/Project/DocumentId and how DocumentState is exposed.

simplified temporary storage service's temporary storage management and added ability to attach to existing temporary storage

solution checksum and serialization service.

added remote host client
- this gives an ability for host (vs) to talk to remote host (service hub)

rename and moving files between feature/workspace layers
- only real change is having ICompilerDiagnosticAnalyzer interface which can either have inproc implementation or out of proc implementation.
- inproc is needed since diagnostics are in feature layer and one who uses feature layer out side of VS host need an implementation.

added RemoteWorkspace
- RemoteWorkspace has host agnostic implementation of roslyn features/services/workspace that will run in remote host

added service hub component and setup project for service hub
- service hub component is basically thin layer that deals with converting data to pass in to RemoteWorkspace

made devdiv insertion tool to ignore servicehub related files

support byte and char array natively in ObjectReader/Writer

It's contained in the diagnostics window VSIX, which we include in
the full deployment.

This reverts commit 7debfc47.

by removing `<DebugType>` lines from projects that import `VSL.Settings.targets`

The intent of the code base was to be run with overflow checking disabled.  However the actual settings were quite a bit different:

- CSharp: checking enabled in debug, disabled in release
- VB: checking disabled in all modes

For both languages individual projects could, and often did, override this setting.  Typically it specified the global default but not always.

This is confusing and makes it difficult to reason about our source code.  Furthermore much of our testing occurs in debug mode and it's not logical for our code to behave substantially different in Debug than it would in Release.

This change clarifies our overflow checking behavior.  It's disabled in all modes now.  The change goes further to prevent individual projects from overriding this setting and adds unit tests to make sure it was applied correctly.

Note: this PR is not intended to state whether it's better for overflow checking to be enabled or disabled.  It is intended to enforce the decision the code base was designed around.

When renaming a VB form, cascade to the synthesized compiler "My" property for the instance of the form.

* This updates all references to nuget.exe to use the copy in the root.
* This deletes all NuGet.config and NuGet.exe files that are not in the root.
* This removes all references to NuGet.targets (which is obsolete and no longer exists)

This change does two actions to our public API files:

- Resets them to the versions from 1.0.0 RTM
- Splits them into the shipped and unshipped files

Plumb the features flag through our MSBuild and Workspaces layers.

closes #3879

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.

Fix breakpoint handling and EnC of queries containing Select and GroupBy clauses that don't translate their select/group-by expression to lambda