Fix link issues

topics/Intro/key_topics.md

@@ -4,7 +4,7 @@ The ReSharper Platform is very large, and very capable, and its size can initial
 
 ## Essential concepts
 
-* [Getting Started](GettingStarted.md) with extensions and plugins.
+* [Getting Started](getting_started.md) with extensions and plugins.
 * [Architectural overview](Architecture_Overview.md) - a brief tour of the different layers of the ReSharper Platform.
 * [Lifetime management](Lifetime.md) - discusses the `Lifetime` class, which is key to lifetime management and used throughout the Platform.
 * [Component Model](Platform_ComponentModel.md) - ReSharper is very much a component based application. All services and components are exported and must be imported in order to be consumed. This allows for a very loose coupled architecture, and is instrumental to making ReSharper very extensible. To get the most out of it requires some understanding of how the component model works, and how it relates to lifetime management.

topics/Platform/Platform_ComponentModel.md

@@ -84,8 +84,6 @@ One downside to wiring up an application through the Component Model is that err
 
 Troubleshooting can initially seem very difficult, due to the cascading errors, all of which will throw exceptions. The important exception is the first one, which will tell you which component failed during creation. The failure will be related to one of the constructor parameters, so each parameter should be checked - is the parameter type a component? Does it come from the same or higher scope (i.e. is a shell component trying to depend on a solution component)? Does the parameter have the correct cardinality (single instance vs. collection)?
 
-ReSharper 9.0 adds better diagnostics for troubleshooting component model failures, describing which parameter caused the issue, and adding more context to the exception's `Data` dictionary. This data is only available in a [checked build](Tools.md).
-
 ## Lazy and optional acquisition
 
 Dependencies can be declared as lazy or optional.
@@ -110,4 +108,4 @@ There are other component attribute types that derive from `ShellComponentAttrib
 
 ### Parts
 
-Components such as shell and solution components, and derived types such as code cleanup module components are the most common usage of the Component Model in ReSharper, supporting known lifetime and usage requirements. However, they are not the only usage. The Component Model implements an Inversion of Control container, populated with "parts", and shell and solution components are implemented as nested components of parts identified by the `[ShellComponent]` and `[SolutionComponent]` attributes. Other components create their own containers for custom lifetime and usage handling. See the [Containers, Parts and Catalogues](ContainersPartsCatalogues.md) section for more details.
+Components such as shell and solution components, and derived types such as code cleanup module components are the most common usage of the Component Model in ReSharper, supporting known lifetime and usage requirements. However, they are not the only usage. The Component Model implements an Inversion of Control container, populated with "parts", and shell and solution components are implemented as nested components of parts identified by the `[ShellComponent]` and `[SolutionComponent]` attributes. Other components create their own containers for custom lifetime and usage handling. See the [Containers, Parts and Catalogues](ContainersPartsCatalogues.md) section for more details.

topics/basics/internal_mode.md

@@ -2,7 +2,7 @@
 
 ReSharper supports an "internal mode" that enables a number of extra features that are normally hidden from end users. These are diagnostic and testing features used by the dev team, and most users will never need to use, however, they can be very useful for extension authors.
 
-Another useful feature is that internal mode also enables exception reporting. In production builds, exceptions are silently logged and not reported to the end user. Checked builds (such as EAP builds) have exception reporting enabled by default, and also include extra contextual information in the [exception's `Data` dictionary](http://msdn.microsoft.com/en-us/library/system.exception.data(v=vs.110).aspx). [Checked builds](Tools.md) are highly recommended when developing extensions.
+Another useful feature is that internal mode also enables exception reporting. In production builds, exceptions are silently logged and not reported to the end user. Checked builds (such as EAP builds) have exception reporting enabled by default, and also include extra contextual information in the [exception's `Data` dictionary](http://msdn.microsoft.com/en-us/library/system.exception.data(v=vs.110).aspx).
 
 ## Enabling internal mode
 
@@ -40,4 +40,4 @@ As well as adding new menu items, enabling internal mode will add new options to
 
 * **Tools → Unit Testing** gets two new options, **Enable Debug** and **Enable Logging**. The "Enable Debug" option will cause the external test runner process to display a message box before running any tests, giving the developer time to attach a debugger.
 * The **Internal** page provides lots of interesting options, most of which are only interesting to the development team (the "Enable Zones" check box falls into this category - it analyses your source code for correct [Zone](Platform_Zones.md) usage, however it doesn't analyse referenced code, so it's not useful for extension developers. This functionality will be added by a separate extension in the future).
-* The **Logging** page allows for creating and editing logging configuration files. The generated configuration file provides comments on how the file works.
+* The **Logging** page allows for creating and editing logging configuration files. The generated configuration file provides comments on how the file works.