Breaks the internal GTD infrastructure into seperate symbols for
determining the navigable symbol at the caret position and performing
the navigation.

Inline Rename performs a rename operation on an initial solution to produce a new solution with all references renamed, conflicts resolved, etc. This new solution may contain linked documents with un-merged (and potentially conflicting) contents. This change applies this linked file merging step to present properly merged changes and rename tags.

If a file on disk D.cs is linked in two Projects P1 and P2, then there are two documents D1 and D2, with their contents being equal. When a symbol is renamed, we have a new solution with documents D1' and D2'. We calculate the text changes between D1 & D1' (C1), and D2 & D2' (C2), and merge these changes C1 and C2 into a final set of changes which produces the new merged Documents, D1m and D2m, with their contents being equal. Each document D1' and D2' knows its rename information, such as the location of definitions, references, and resolved/unresolved conflicts. This information is mapped to D1m/D2m for display in the editor by tracking spans from D1' to D1m, and D2' to D2m. The final locations of these tracking spans is their location in the merged buffer contents. (changeset 1389424)

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)

Automatic text-based merging of divergent edits made to linked files during Workspace.TryApplyChanges.

Changes that are easily merged because they are identical or isolated (a change span that overlaps no other change spans in any linked document) are simply updated to reflect the new text. In the case of isolated changes, - we assume that the change happened in a #if region and it is therefore safe to apply the change.

Once these straightforward changes are applied, the remaining changes which cannot be easily merged because they conflict with another edit are added to the final text in a commented form. If we start with a reference to a class C but a refactoring fully qualifies it as "A.B.C" in one linked document but as "B.C" in another, the following comment is emitted into source:

/* Unmerged change from project 'ProjectName'
Before:
C
After:
B.C
*/
A.B.C

This change also prevents the Preview Changes dialog from showing multiple copies of linked documents. (changeset 1295841)