***NO_CI***
 (changeset 1367780)

CodeFixProvider:
1. "Task<IEnumerable<CodeAction>> GetFixesAsync(CodeFixContext)" becomes "Task ComputeFixesAsync(CodeFixContext)".
2. CodeFixContext now has a new method - "void RegisterFix(CodeAction, IEnumerable<Diagnostic>>)".

This API now allows providers to map each returned code action to the set of diagnostics being fixed by this code action.

CodeRefactoringProvider gets identical API changes for consistency:
3. "Task<IEnumerable<CodeAction>> GetRefactoringsAsync(CodeFixContext)" becomes "Task ComputeRefactoringsAsync(CodeFixContext)".
4. CodeRefactoingContext now has a new method - "void RegisterRefactoring(CodeAction)".

Also moves all our existing fix and refactoring providers (including samples and sdk templates) over to the new API. (changeset 1363085)

Rollback code fix public API changes checked in in C1353855. This takes us closer to proposed new API that I am currently working on. (changeset 1360209)

Currently, we have a many to many mapping between diagnostics reported in a given span and code fixes available for these diagnostics. For example, it is legal for a code fix provider to return two fixes to handle three diagnostics in a given span and we currently have no way to map from the fixes returned from a provider back to the diagnostics that each fix is supposed to handle (the CodeAction for a fix doesn't know which diagnostic it is fixing)

The light bulb menu item (SuggestedAction) for a fix therefore doesn't have a definitive way to identify which diagnostic the menu item is fixing. Instead each SuggestedAction holds on to a collection of diagnostics and it could be fixing any diagnostic in the collection. In the preview pane header for a particular menu item, we currently display details about the 'first' diagnostic in the collection. Most of the time this works fine because most of the time we only have a single diagnostic in any given span. However this breaks anytime we have more than one diagnostic in a given span and we end up showing the wrong headers for our preview panes in such cases.

This fix changes code fix providers to always accept a single diagnostic as input (instead of a collection) and return a list of fixes for this single diagnostic (i.e. have one to many mapping from diagnostic to fixes). The host now passes one diagnostic at a time to each provider which returns set of fixes for each diagnostic. This allows the host to maintain a mapping from diagnostic to fixes and display this mapping to the end user (in the preview pane header) + also makes the API less confusing for the author of the fix provider. (changeset 1353855)

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)

This change introduces following context objects:
(a) CodeFixContext struct which is passed into CodeFixProvider.GetFixesAsync method and
(b) CodeRefactoringContext struct which is passed into CodeRefactoringProvider.GetRefactoringsAsync. (changeset 1345537)

Change ICodeFixProvider (interface) to CodeFixProvider (abstract type) and ICodeRefactoringProvider (interface) to CodeRefactoringProvider (abstract type) (changeset 1344836)

User story 862192: FixAllProvider API and default fix all implementations (replace "Fix All Occurrences")

Changes include:
1) Add a new abstract type, FixAllProvider, in Workspaces layer to represent a provider which can provide "fix all occurrences" code fixes corresponding to fixes provided by an ICodeFixProvider.

2) Add a new API on ICodeFixProvider (GetFixAllProvider()) to get an optional FixAllProvider. Implementers can return null to indicate no fix all support. Otherwise, they can either return an instance any of the well known implementations (see (3) below) or return an instance of their own implementation of FixAllProvider.

3) Provide default implementation of a batch FixAllProvider which works for simple code fix providers which return code actions which have a single document change action. This provider batches all the individual diagnostic fixes across the scope of fix all action, computes fixes in parallel and and then merges all the non-conflicting fixes into a single fix all code action. For more complex scenarios, users must write their own FixAllProvider implementation.

4) Add the following public types for FixAllProvider:
  (a) FixAllScope: Represents the scope in which fix all occurrences will be applied (document/project/solution/custom)
  (b) FixAllContext: Context information for computing fix all fixes. This context object is passed into FixAllProvider.GetFix API.

5) Add an optional string property "Id" on CodeAction. This string defines a unique Id amongst all code actions returned by an ICodeFixProvider, and is part of the FixAllContext to determine which code action is applied at all fix locations.

6) Enable fix all support for following code fixes:
  (a) Simplify type names
  (b) Remove unnecessary cast
  (c) Remove unncessary usings
  (d) Implement interface/abstract type

7) Fix All Occurrences UI: Currently, these FixAllOccurrences code fixes will show up as hyperlinks in code fix preview pane. Clicking on these will trigger computation of diagnostics and fix all fixes for the chosen scope. Subsequently, preview changes dialog will come up to preview the fix.
Post preview, these hyperlinks will be replaced with lightbulb sub menus under the original code fix. (changeset 1341442)

Moving the samples we ship with our SDK to open source.  Also including the interns analyzers, code fixes, and tests. (changeset 1314543)