This change moves the contents of VisualStudioSetup into the open,
merging with (and consuming) VisualStudioComponents. The Components/
Setup split originally existed as a way to allow multiple Roslyn-using
components to have a single source of truth of the MEF exports. This
meant you could have either the interactive window, language services,
or both installed and everything worked. This was important when we
were atop Visual Studio 2013, but now that we're integrated it's buying
us nothing.

The VSIX ID from VisualStudioComponents is preserved so that way any
extensions that declared a dependency on it will still work.

This change allows provides the option of running our tests in 64 bit
mode.  Simply invoke BuildAndTest.proj in the following manner:

> msbuild /v:m /m BuildAndTest.proj /p:Test64=true

There are a set of tests today that don't run correctly in 64.  All have
been annotated with the trait

> Require32=true

We need to push on these to get a clean 64 bit run.  But short term this
will at least give us protection against regressions.

Put ExpressionEvaluator projects back into "Core", "CSharp", "Setup", "VisualBasic" folders in Roslyn.sln...

Currently tests are run on the developers machine using

> msbuild BuildAndTest.proj

This takes ~25 minutes to complete on the CI machine and ~45 minutes on
a developer machine (developer machines run a greater number of suites).
This is not conductive to quick bug fixes.

Ideally the infrastructure would switch over to using xunit 2 which can
handle parallelizing the tests for us.  Unfortunately this isn't an
option because:

1. The 32 bit runner quickly OOMS on our suites
2. A number of our tests can't run in 64 bit

Long term xunit2 is still our goal.  Short term though this tool will
use process level parallelization to run our suites.

The guids for the new analyzer projects were copied from the codeanalysisanalyzers but since the codeanalysisanalyzers werent part of the solution VS didnt know. Once I merged the change that added them to the solution, VS got confused. Fixing the guids.

Also adding newlines to the end.

Move rule CA1001 to this project. Rewrite the codefixer for it to be based on DocumentEditor and hence language agnostic.

Fix for CA1001 shouldn't generate a dispose method if there is already one in the type. Instead modify that method to make it the interface implementation.
Adding some tests.

Fix #323 bug in SemanticModel.GetAwaitExpressionInfo when await expression used as an expression statement.

It looks like this got lost when the new open Roslyn.sln was created.

The project wasn't fully removed from the solution so NuGet restore
complained about the project not existing when run on the solution. (changeset 1410281)

Bug-1116460 : Renaming the scripting assemblies and namespaces. Making corresponding changes in InstallDogfood and RoslynBuildAndTtest to account for new names (changeset 1408119)

 Change Description:

     This change moves Roslyn off of our custom version of xUnit to an official release (xUnit 1.9.2):

     - Deletes all of the custom xUnit binaries from Closed\Tools\xUnit
     - Put a subset of the official 1.9.2 binaries with no name mangling into Closed\Tools\xUnit.
     - Rebuilt our custom xUnit GUI (named xunit.gui.custom) against 1.9.2 and put it in Closed\Tools\xUnit
     - Updated the targets file, RunTests.ps1 and Test.exe to refer to the updated binary names.
     - Changed the Roslyn unit tests to work on standard xUnit.

     The biggest part of the effort was the last part, getting the tests to run on standard xUnit.  The main issue here was many assumed they would be executed on a single STA thread and as a result cached many thread affinitized values into static fields.  Fixing this involved mostly finding the values and annotating them with [ThreadStatic].

     This does mean that MEF composition will happen several times during an xUnit run where before it happened only once.  That is unfortunate but doesn't seem to regress the suites in a significant way on my machine.  Using a multithreaded MEF container isn't an option here because the services end up caching thread affinitized WPF values.

     ForegroudThreadAffinitizedObject was the other largest change.  It's use of a static ctor to establish the foreground thread is dangerous and should be correctly addressed in a future change.  For now I added a method for tests to reset the identified foreground thread.

     More changes will be coming here for our use of xUnit.  But they should be smaller and more targetted (deleting the extra sources, a better build story for the GUI, etc ...).

     Note: Why 1.9.2 instead of 2.0?  We have several uses of custom xUnit extensibility that is not easily portable to 2.0.  Best path forward is to delete that extensibility since it isn't really adding much and move us directly onto 2.0 in a later check in.

 (changeset 1395675)

***NO_CI***
 (changeset 1384854)

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)

Create a project for a vbcsc2ui.dll to hold resource used by vbc2.exe and csc2.exe. (changeset 1346108)

messages.

The new native client is written in C++11 to be more maintainable and
forward-looking. The native client is a static library, which is now
linked into the csc2 and vbc2 projects instead of having a single csc2.cpp
file which is shared between the two projects and built for each based on
a preprocessor definition.

The MSBuildTask is also configured to use csc2/vbc2 and feature no extra
code for Roslyn, which will prevent us from having to maintain both a
native and a managed version of the client. (changeset 1325415)

In order to validate warning ids that can appear within #Disable directives in VB, we need to generate an ErrorFacts helper that will tell us precisely whether or not the specified id is a valid VB warning id (similar to what C# uses to do corresponding validation within #pragmas).

This change adds a simple ErrorFacts generator tool that will be invoked as part of building VB. The implementation is identical to the ErrorFacts generator for C#. (changeset 1287001)

rcsc to csc
rcsi to csi
rcsc2 to csc2
rvbc to vbc
rvbi to vbi
rvbc2 to vbc2
 (changeset 1285266)

Splits Microsoft.CodeAnalysis, Microsoft.CodeAnalysis.CSharp and Microsoft.CodeAnalysis.VisualBasic into portable and desktop assemblies.

Existing Core\Source, CSharp\Source and VisualBasic\Source directories are renamed to Core\Portable, CSharp\Portable and VisualBasic\Portable.
New sibling Desktop folders are added and non-portable source is moved there.
"System.Runtime" references has to be removed in order for the portable project system magic to automatically add facade references.
 (changeset 1281686)

Fix DiagnosticAnalyzer project GUIDs and add missing build configurations for the Visualizer projects. (changeset 1234903)