Changed docs.microsoft.com/dotnet URLs to relative URLs

Documentation/compatibility/change-in-path-separator-character-in-zip-files.md

@@ -22,15 +22,15 @@ Decompressing a zip file created by an app that targets a previous version of th
 
 The impact of this change on .ZIP files that are decompressed on the Windows operating system by APIs in the .NET Framework <xref:System.IO?displayProperty=nameWithType> namespace should be minimal, since these APIs can seamlessly handle either a slash ("`/`") or a backslash ("`\`") as the path separator character.  
 
-If this change is undesirable, you can opt out of it by adding a configuration setting to the [`<runtime>`](https://docs.microsoft.com/dotnet/framework/configure-apps/file-schema/runtime/runtime-element.md) section of your application configuration file. The following example shows both the `<runtime` section and the `Switch.System.IO.Compression.ZipFile.UseBackslash` opt-out switch:
+If this change is undesirable, you can opt out of it by adding a configuration setting to the [`<runtime>`](~/docs/framework/configure-apps/file-schema/runtime/runtime-element.md) section of your application configuration file. The following example shows both the `<runtime>` section and the `Switch.System.IO.Compression.ZipFile.UseBackslash` opt-out switch:
 
 ```xml
 <runtime>
    <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=true" />
 </runtime>
 ```
 
-In addition, apps that target previous versions of the .NET Framework but are running on the .NET Framework 4.6.1 and later versions can opt in to this behavior by adding a configuration setting to the [`<runtime>`](https://docs.microsoft.com/dotnet/framework/configure-apps/file-schema/runtime/runtime-element.md) section of the application configuration file. The following shows both the `<runtime>` section and the `Switch.System.IO.Compression.ZipFile.UseBackslash` opt-in switch.
+In addition, apps that target previous versions of the .NET Framework but are running on the .NET Framework 4.6.1 and later versions can opt in to this behavior by adding a configuration setting to the [`<runtime>`](~/docs/framework/configure-apps/file-schema/runtime/runtime-element.md) section of the application configuration file. The following shows both the `<runtime>` section and the `Switch.System.IO.Compression.ZipFile.UseBackslash` opt-in switch.
 
 ```xml
 <runtime>

Documentation/compatibility/new-64-bit-jit-compiler.md

@@ -37,7 +37,7 @@ If you encounter the issues listed above, you can address them by doing any of t
 **Mitigation of other issues**  
 If you encounter any other difference in behavior between code compiled with the older 64-bit compiler and the new 64-bit JIT compiler, or between the debug and release versions of your app that are both compiled with the new 64-bit JIT compiler, you can do the following to compile your app with the older 64-bit JIT compiler:  
 
-- On a per-application basis, you can add the [\<useLegacyJit>](https://docs.microsoft.com/dotnet/framework/configure-apps/file-schema/runtime/uselegacyjit-element) element to your application's configuration file. The following disables compilation with the new 64-bit JIT compiler and instead uses the legacy 64-bit JIT compiler.  
+- On a per-application basis, you can add the [\<useLegacyJit>](~/docs/framework/configure-apps/file-schema/runtime/uselegacyjit-element.md) element to your application's configuration file. The following disables compilation with the new 64-bit JIT compiler and instead uses the legacy 64-bit JIT compiler.  
 
    ```xml  
    <?xml version ="1.0"?>  

Documentation/compatibility/product-versioning-changes-in-net-framework-4-6-and-later.md

@@ -24,15 +24,15 @@ The following are the detailed changes:
 
 - In the .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, and 4.7.1, the <xref:System.Environment.Version?displayProperty=nameWithType> property returns the fixed version string `4.0.30319.42000`. In the .NET Framework 4, 4.5, 4.5.1, and 4.5.2, it returns version strings in the format `4.0.30319.xxxxx` (for example, "4.0.30319.18010"). Note that we do not recommend application code taking any new dependency on the Environment.Version property.
 
-For more information, see [How to: Determine which .NET Framework Versions Are Installed](https://docs.microsoft.com/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed).
+For more information, see [How to: Determine which .NET Framework Versions Are Installed](~/docs/framework/migration-guide/how-to-determine-which-versions-are-installed.md).
 
 - [ ] Quirked 
 - [ ] Build-time break 
 
 ### Recommended Action
 In general, applications should depend on the recommended techniques for detecting such things as the runtime version of the .NET Framework and the installation directory:
 
-- To detect the runtime version of the .NET Framework, see [How to: Determine Which .NET Framework Versions Are Installed](https://docs.microsoft.com/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed.md).
+- To detect the runtime version of the .NET Framework, see [How to: Determine Which .NET Framework Versions Are Installed](~/docs/framework/migration-guide/how-to-determine-which-versions-are-installed.md).
 
 - To determine the installation path for the .NET Framework, use the value of the `InstallPath` entry in the `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full` key.
 

Documentation/compatibility/servicepointmanager.securityprotocol-defaults-to-securityprotocoltype.systemdefault.md

@@ -10,19 +10,19 @@ Minor
 NotPlanned
 
 ### Change Description
-Starting with apps that target the .NET Framework 4.7, the default value of the <xref:System.Net.ServicePointManager.SecurityProtocol?displayProperty=nameWithType> property is <xref:System.Net.SecurityProtocolType.SystemDefault?displayProperty=nameWithType>. This change allows .NET Framework networking APIs based on SslStream (such as FTP, HTTPS, and SMTP) to inherit the default security protocols from the operating system instead of using hard-coded values defined by the .NET Framework. The default varies by operating system and any custom configuration performed by the system administrator. For information on the default SChannel protocol in each version of the Windows operating system, see [Protocols in TLS/SSL (Schannel SSP)](https://msdn.microsoft.com/library/windows/desktop/mt808159.aspx).
+Starting with apps that target the .NET Framework 4.7, the default value of the <xref:System.Net.ServicePointManager.SecurityProtocol?displayProperty=nameWithType> property is <xref:System.Net.SecurityProtocolType.SystemDefault?displayProperty=nameWithType>. This change allows .NET Framework networking APIs based on SslStream (such as FTP, HTTPS, and SMTP) to inherit the default security protocols from the operating system instead of using hard-coded values defined by the .NET Framework. The default varies by operating system and any custom configuration performed by the system administrator. For information on the default SChannel protocol in each version of the Windows operating system, see [Protocols in TLS/SSL (Schannel SSP)](https://msdn.microsoft.com/library/windows/desktop/mt808159.aspx).</p>
 
 For applications that target an earlier version of the .NET Framework, the default value of the <xref:System.Net.ServicePointManager.SecurityProtocol?displayProperty=nameWithType> property depends on the version of the .NET Framework targeted. See the [Networking section of Retargeting Changes for Migration from .NET Framework 4.5.2 to 4.6](~/docs/framework/migration-guide/retargeting/4.5.2-4.6.md#networking) for more information.
 
 - [X] Quirked
 - [ ] Build-time break
 
 ### Recommended Action
-This change affects applications that target the .NET Framework 4.7 or later versions.
+This change affects applications that target the .NET Framework 4.7 or later versions. </br>
 
-If you prefer to use a defined protocol rather than relying on the system default, you can explicitly set the value of the <xref:System.Net.ServicePointManager.SecurityProtocol?displayProperty=nameWithType> property.
+If you prefer to use a defined protocol rather than relying on the system default, you can explicitly set the value of the <xref:System.Net.ServicePointManager.SecurityProtocol?displayProperty=nameWithType> property.</br>
 
-If this change is undesirable, you can opt out of it by adding a configuration setting to the [`<runtime>`](https://docs.microsoft.com/dotnet/framework/configure-apps/file-schema/runtime/runtime-element) section of your application configuration file. The following example shows both the `<runtime>` section and the `Switch.System.Net.DontEnableSystemDefaultTlsVersions` opt-out switch:
+If this change is undesirable, you can opt out of it by adding a configuration setting to the [`<runtime>`](~/docs/framework/configure-apps/file-schema/runtime/runtime-element.md) section of your application configuration file. The following example shows both the `<runtime>` section and the `Switch.System.Net.DontEnableSystemDefaultTlsVersions` opt-out switch:
 
 ```xml
 <runtime>

Documentation/compatibility/tls-1-x-by-default-passes-sch-send-aux-record-flag-to-the-underlying-schannel-api.md

@@ -20,7 +20,7 @@ In rare cases, this breaks communication between clients and existing servers th
 
 ### Recommended Action
 
-If this change breaks communication with an existing server, you can disable sending the [`SCH_SEND_AUX_RECORD`](https://msdn.microsoft.com/library/windows/desktop/aa379810.aspx) flag and restore the previous behavior of not splitting data into separate records by adding the following switch to the [`\<AppContextSwitchOverrides>` element](~/docs/framework/configure-apps/file-schema/runtime/appcontextswitchoverrides-element.md) in the [`\<runtime> section](~/docs/framework/configure-apps/file-schema/runtime/runtime-element.md) of your app configuration file:
+If this change breaks communication with an existing server, you can disable sending the [`SCH_SEND_AUX_RECORD`](https://msdn.microsoft.com/library/windows/desktop/aa379810.aspx) flag and restore the previous behavior of not splitting data into separate records by adding the following switch to the [`<AppContextSwitchOverrides>`](~/docs/framework/configure-apps/file-schema/runtime/appcontextswitchoverrides-element.md) element in the [`<runtime>`](~/docs/framework/configure-apps/file-schema/runtime/runtime-element.md) section of your app configuration file:
 
 ```xml
 <runtime>