Fixup doc links to use relative paths

Author: JoeRobich

docs/C#-Extension-support-for-new-Linux-Distros-with-.NET-Core.md

@@ -9,7 +9,7 @@ In this case the C# extension team should be able to produce a new version of th
 In this case it is just a matter of tweaking this [switch statement](https://github.com/dotnet/vscode-csharp/blob/a0d803fb0e30832b3a8c034e938c2e97662f9788/src/platform.ts#L226) which parses the output from `cat /etc/os-release`. While we cannot commit to testing on these unofficial distros we are happy to accept a PR to enable the distro, and if there are minor bugs in the debugger we are happy to try and fix them as well.
 
 ### 3: The community has produced a .NET Core install script, and the public vsdbg can run
-For these distributions, the [debugger installer class](https://github.com/dotnet/vscode-csharp/blob/master/src/coreclr-debug/install.ts) can be run as a [gulp task](https://github.com/dotnet/vscode-csharp/blob/bc2eb6e5ec90f3b2c9e5a45e3aadd47e28539d01/gulpfile.js#L64). So it might be possible for the community to provide an install script which will find the current installed C# extension, use gulp to have the debugger and OmniSharp download the version of the extension from some other Linux distro, and then patch the CoreCLR/FX which they are running on. The C# extension team is happy to accept tweaks to the install code to make this easier.
+For these distributions, the [debugger installer class](https://github.com/dotnet/vscode-csharp/blob/main/src/coreclr-debug/install.ts) can be run as a [gulp task](https://github.com/dotnet/vscode-csharp/blob/bc2eb6e5ec90f3b2c9e5a45e3aadd47e28539d01/gulpfile.js#L64). So it might be possible for the community to provide an install script which will find the current installed C# extension, use gulp to have the debugger and OmniSharp download the version of the extension from some other Linux distro, and then patch the CoreCLR/FX which they are running on. The C# extension team is happy to accept tweaks to the install code to make this easier.
 
 ### 4: New vsdbg is needed
 vsdbg is the cross-platform .NET Core debugger backend. It is based on the same debugger as Visual Studio, and so is a closed-sound product. Distributions where the current public version of vsdbg cannot run are difficult to deal with. In general, we would need official support from the .NET Core team in these cases. Though feel free to open an [issue](https://github.com/dotnet/vscode-csharp/issues) to discuss the problem.

docs/How-to-run-and-debug-unit-tests.md

@@ -1,13 +1,13 @@
 The C# extension currently supports running and debugging a unit test via CodeLens annotations on test methods. Just click the 'run test' or 'debug test' links:
 
-![CodeLens](https://raw.githubusercontent.com/wiki/OmniSharp/omnisharp-vscode/images/unit-test-codelens.png)
+![CodeLens](./images/unit-test-codelens.png)
 
 ### Notes
 
 * Because `dotnet test` will run the test code in a child process, it isn't possible to configure a "unit test debugging" configuration in launch.json
 * There currently isn't a VS Code command to run the current test, though there is an [issue for this in the backlog](https://github.com/dotnet/vscode-csharp/issues/421).
-* You can tweak [debugging options](https://github.com/dotnet/vscode-csharp/blob/master/debugger-launchjson.md) for unit tests by opening your VS Code settings file (ex: File->Preferences->Settings on Windows), and configuring the `"csharp.unitTestDebuggingOptions"` setting. See example below.
-* If your unit tests are targeting .NET Framework instead of .NET Core, see [Desktop .NET Framework](https://github.com/dotnet/vscode-csharp/wiki/Desktop-.NET-Framework) for more information.
+* You can tweak [debugging options](../debugger-launchjson.md) for unit tests by opening your VS Code settings file (ex: File->Preferences->Settings on Windows), and configuring the `"csharp.unitTestDebuggingOptions"` setting. See example below.
+* If your unit tests are targeting .NET Framework instead of .NET Core, see [Desktop .NET Framework](./debugger/Desktop-.NET-Framework.md) for more information.
 
 Example User Settings file with unit test debugging options:
 

docs/Reporting-Issues.md

@@ -11,5 +11,5 @@ The extension supports the command that populates the necessary information from
     * In the output pane on the right, you should see an "OmniSharp log" in the drop-down
     * Paste the output from here to the "OmniSharp log" section
 
-    ![OmniSharp log](images/omnisharp_log.png)
+    ![OmniSharp log](./images/omnisharp_log.png)
     * The C# log can also be found in the same window.

docs/Troubleshooting:-'The-.NET-Core-SDK-cannot-be-located.'-errors.md

@@ -70,8 +70,6 @@ Note that, as of the time of this writing, there are also other incompatibilitie
 
 More information about this problem can be found in [dotnet/cli#12110](https://github.com/dotnet/cli/issues/12110).
 
-Some community members have been successful in using the Snap install by following the instructions listed in [Configuring Snap installs of dotnet-sdk](https://github.com/dotnet/vscode-csharp/wiki/Configuring-Snap-installs-of-dotnet-sdk).
-
 Another possible workaround is to add the following to `~/.omnisharp/omnisharp.json`.
 
 ```json

docs/debugger/Attaching-to-remote-processes.md

@@ -91,7 +91,7 @@ Last, to be able to debug obviously the application must somehow be runnable on
 
 There are two special concerns in this area when it comes to debugging:
 
-1. Debug vs. Release Configuration: If you are going to be debugging, the experience is going to be much better if the debug configuration of your application is running instead of the release configuration. If this isn't possible, one can debug release code. To do this, disable [justMyCode](https://github.com/dotnet/vscode-csharp/blob/release/debugger.md#just-my-code) in launch.json.
+1. Debug vs. Release Configuration: If you are going to be debugging, the experience is going to be much better if the debug configuration of your application is running instead of the release configuration. If this isn't possible, one can debug release code. To do this, disable [justMyCode](../../debugger.md#just-my-code) in launch.json.
 2. PDB files: In order for VSDBG to be able to be able to map executable code back to its source code (or vice versa) VSDBG needs to have PDB files. If you are already building your application on the target server, this is taken care of for you. If you are building it somewhere else, you need to make sure to copy the PDB files next to their associated dll or set the DebugType to 'embedded' so that the PDB data is kept inside of the compiled dll.
 
 ### Configuring Docker attach with launch.json
@@ -156,7 +156,7 @@ If vsdbg is crashing or being aborted a few additional troubleshooting steps:
 
 #### 1: Check for libicu compatibility
 
-See the [Testing libicu compatibility on Linux](https://github.com/dotnet/vscode-csharp/wiki/Testing-libicu-compatibility-on-Linux) page for more information.
+See the [Testing libicu compatibility on Linux](./Testing-libicu-compatibility-on-Linux.md) page for more information.
 
 #### 2: Save a coredump of a possible vsdbg crash
 

docs/debugger/Desktop-.NET-Framework.md

@@ -1,12 +1,12 @@
-The C# extension supports limited full .NET framework debugging. It can only debug 64-bit applications with [portable PDBs](https://github.com/dotnet/vscode-csharp/wiki/Portable-PDBs).
+The C# extension supports limited full .NET framework debugging. It can only debug 64-bit applications with [portable PDBs](./Portable-PDBs.md).
 
 To enable the Desktop CLR debugger, change the configuration type in launch.json to be "clr" instead of "coreclr" and program should be pointing at the exe (**NOT** a .dll).
 
 For unit tests, this can be done thusly:
 1. File->Preferences->Settings
 2. Open "CSharp: Unit Test Debugging Options"
 3. Set the 'type' to 'clr' (see settings.json example below)
-4. NOTE: For MSTest projects, also see [Forcing MSTest projects to use a 64-bit worker](https://github.com/dotnet/vscode-csharp/wiki/Desktop-.NET-Framework#forcing-mstest-projects-to-use-a-64-bit-worker) section.
+4. NOTE: For MSTest projects, also see [Forcing MSTest projects to use a 64-bit worker](./Desktop-.NET-Framework.md#forcing-mstest-projects-to-use-a-64-bit-worker) section.
 
 ## launch.json example
 

docs/debugger/Diagnosting-'Debug-adapter-process-has-terminated-unexpectedly'.md

@@ -1,7 +1,7 @@
 If Visual Studio code displays "Debug adapter process has terminated unexpectedly", and the debug console doesn't have information about why, this generally means that the debugger process (vsdbg-ui) crashed. Here is some information you can provide us to diagnose what went wrong.
 
 ### Common
-On all OSs, it can be useful to have [logging enabled](https://github.com/dotnet/vscode-csharp/wiki/Enabling-C%23-debugger-logging), and to provide the last bit of the event log.
+On all OSs, it can be useful to have [logging enabled](Enabling-C#-debugger-logging.md), and to provide the last bit of the event log.
 
 ### macOS
 
@@ -10,7 +10,7 @@ On all OSs, it can be useful to have [logging enabled](https://github.com/dotnet
 3. Copy paste the 'Exception Type', 'Exception Codes' and 'Exception Note' section into the GitHub issue.
 4. Also look at the 'Crashed Thread', then find the call stack for that thread, and send that too (see example below).
 
-![macOS console screen shot](https://raw.githubusercontent.com/wiki/OmniSharp/omnisharp-vscode/images/OSXConsoleUtility.png)
+![macOS console screen shot](../images/OSXConsoleUtility.png)
 
 ```
 Thread 9 Crashed:

docs/debugger/Troubleshoot-Breakpoints.md

@@ -2,7 +2,7 @@
 
 When debugging, a breakpoint has two possible visual states: a solid red circle and a hollow grey circle. If the debugger is able to successfully set a breakpoint in the target process, it will stay a solid red circle. If the breakpoint is a hollow circle a warning has occurred when trying to set the breakpoint. To see the warning, hover over the breakpoint in the debug view:
 
-![Breakpoints Window](https://raw.githubusercontent.com/wiki/OmniSharp/omnisharp-vscode/images/breakpoints-window.png)
+![Breakpoints Window](../images/breakpoints-window.png)
 
 The following two sections describe prominent warnings and how to fix them.
 
@@ -16,7 +16,7 @@ If the line exists, did symbols load?
 
 * If symbols are not loaded:
   * Did the debugger provide additional information in the log lines around this?
-  * If the dll is being loaded from a different directory from where it was originally built, you may need to add an additional directory through the symbol search path -- in your launch.json file, add a "symbolsOptions/searchPaths" section ([documentation](https://github.com/dotnet/vscode-csharp/blob/master/debugger-launchjson.md#symbol-options)).
+  * If the dll is being loaded from a different directory from where it was originally built, you may need to add an additional directory through the symbol search path -- in your launch.json file, add a "symbolsOptions/searchPaths" section ([documentation](../../debugger-launchjson.md#symbol-options)).
 * If symbols are loaded, the PDB does not contain information about your source files. These are a few possible causes:
   * If your source files were recently added, confirm that an up-to-date version of the module is being loaded.
   * The PDB file is partially corrupted. Delete the file and perform a clean build of the module to try to resolve the issue.

docs/debugger/Windows-Subsystem-for-Linux.md

@@ -106,6 +106,6 @@ Notes:
 4. File and paths are case sensitive in Linux.
 
 ## Also see
-[Configuring C# Launch.json](https://github.com/dotnet/vscode-csharp/blob/master/debugger-launchjson.md)
+[Configuring C# Launch.json](../../debugger-launchjson.md)
 
 [C++ debugging in WSL with VSCode C++ Extensions.](https://github.com/Microsoft/vscode-cpptools/blob/master/Documentation/Debugger/gdb/Windows%20Subsystem%20for%20Linux.md)