Inline links (#10339)

Author: nxtn

docs/core/deploying/deploy-with-cli.md

@@ -32,11 +32,11 @@ Looking for some quick help on using the CLI? The following table shows some exa
 
 ## Publishing basics
 
-The `<TargetFramework>` setting of the project file specifies the default target framework when you publish your app. You can change the target framework to any valid [Target Framework Moniker (TFM)](../../standard/frameworks.md). For example, if your project uses `<TargetFramework>netcoreapp2.2</TargetFramework>`, a binary that targets .NET Core 2.2 is created. The TFM specified in this setting is the default target used by the [`dotnet publish`][dotnet-publish] command.
+The `<TargetFramework>` setting of the project file specifies the default target framework when you publish your app. You can change the target framework to any valid [Target Framework Moniker (TFM)](../../standard/frameworks.md). For example, if your project uses `<TargetFramework>netcoreapp2.2</TargetFramework>`, a binary that targets .NET Core 2.2 is created. The TFM specified in this setting is the default target used by the [`dotnet publish`](../tools/dotnet-publish.md) command.
 
 If you want to target more than one framework, you can set the `<TargetFrameworks>` setting to more than one TFM value separated by a semicolon. You can publish one of the frameworks with the `dotnet publish -f <TFM>` command. For example, if you have `<TargetFrameworks>netcoreapp2.1;netcoreapp2.2</TargetFrameworks>` and run `dotnet publish -f netcoreapp2.1`, a binary that targets .NET Core 2.1 is created.
 
-Unless otherwise set, the output directory of the [`dotnet publish`][dotnet-publish] command is `./bin/<BUILD-CONFIGURATION>/<TFM>/publish/`. The default **BUILD-CONFIGURATION** mode is **Debug** unless changed with the `-c` parameter. For example, `dotnet publish -c Release -f netcoreapp2.1` publishes to `myfolder/bin/Release/netcoreapp2.1/publish/`. 
+Unless otherwise set, the output directory of the [`dotnet publish`](../tools/dotnet-publish.md) command is `./bin/<BUILD-CONFIGURATION>/<TFM>/publish/`. The default **BUILD-CONFIGURATION** mode is **Debug** unless changed with the `-c` parameter. For example, `dotnet publish -c Release -f netcoreapp2.1` publishes to `myfolder/bin/Release/netcoreapp2.1/publish/`. 
 
 If you use .NET Core SDK 3.0, the default publish mode for apps that target .NET Core versions 2.1, 2.2, or 3.0 is framework-dependent executable.
 
@@ -89,7 +89,7 @@ Module Program
 End Module
 ```
 
-When you run the app ([`dotnet run`][dotnet-run]), the following output is displayed:
+When you run the app ([`dotnet run`](../tools/dotnet-run.md)), the following output is displayed:
 
 ```terminal
   _   _      _ _         __        __         _     _ _
@@ -157,6 +157,3 @@ You must use the following switches with the `dotnet publish` command to publish
 
 - [.NET Core Application Deployment Overview](index.md)
 - [.NET Core Runtime IDentifier (RID) catalog](../rid-catalog.md)
-
-[dotnet-publish]: ../tools/dotnet-publish.md
-[dotnet-run]: ../tools/dotnet-run.md

docs/core/porting/project-structure.md

@@ -9,7 +9,7 @@ ms.custom: seodec18
 
 Learn how to create a solution that compiles for both .NET Framework and .NET Core side-by-side. See several options to organize projects to help you achieve this goal. Here are some typical scenarios to consider when you're deciding how to setup your project layout with .NET Core. The list may not cover everything you want; prioritize based on your project's needs.
 
-* [**Combine existing projects and .NET Core projects into single projects**][option-csproj]
+* [**Combine existing projects and .NET Core projects into single projects**](#replace-existing-projects-with-a-multi-targeted-net-core-project)
 
   *What this is good for:*
   * Simplifying your build process by compiling a single project rather than compiling multiple projects, each targeting a different .NET Framework version or platform.
@@ -20,7 +20,7 @@ Learn how to create a solution that compiles for both .NET Framework and .NET Co
   *Unsupported scenarios:*
   * Requires developers to use Visual Studio 2017 to open existing projects. To support older versions of Visual Studio, [keeping your project files in different folders](#support-vs) is a better option.
 
-* <a name="support-vs"></a>[**Keep existing projects and new .NET Core projects separate**][option-csproj-folder]
+* <a name="support-vs"></a>[**Keep existing projects and new .NET Core projects separate**](#keep-existing-projects-and-create-a-net-core-project)
 
   *What this is good for:*
   * Continuing to support development on existing projects without having to upgrade for developers/contributors who may not have Visual Studio 2017.
@@ -30,31 +30,31 @@ Learn how to create a solution that compiles for both .NET Framework and .NET Co
 
 Consider the repository below:
 
-![Existing project][example-initial-project]
+![Existing project](media/project-structure/project.png)
 
-[**Source Code**][example-initial-project-code]
+[**Source Code**](https://github.com/dotnet/samples/tree/master/framework/libraries/migrate-library/)
 
 The following describes several ways to add support for .NET Core for this repository depending on the constraints and complexity of the existing projects.
 
 ## Replace existing projects with a multi-targeted .NET Core project
 
 Reorganize the repository so that any existing *\*.csproj* files are removed and a single *\*.csproj* file is created that targets multiple frameworks. This is a great option because a single project is able to compile for different frameworks. It also has the power to handle different compilation options and dependencies per targeted framework.
 
-![Create an csproj that targets multiple frameworks][example-csproj]
+![Create an csproj that targets multiple frameworks](media/project-structure/project.csproj.png)
 
-[**Source Code**][example-csproj-code]
+[**Source Code**](https://github.com/dotnet/samples/tree/master/framework/libraries/migrate-library-csproj/)
 
 Changes to note are:
 
-* Replacement of *packages.config* and *\*.csproj* with a new [.NET Core *\*.csproj*][example-csproj-netcore]. NuGet packages are specified with `<PackageReference> ItemGroup`.
+* Replacement of *packages.config* and *\*.csproj* with a new [.NET Core *\*.csproj*](https://github.com/dotnet/samples/tree/master/framework/libraries/migrate-library-csproj/src/Car/Car.csproj). NuGet packages are specified with `<PackageReference> ItemGroup`.
 
 ## Keep existing projects and create a .NET Core project
 
 If there are existing projects that target older frameworks, you may want to leave these projects untouched and use a .NET Core project to target future frameworks.
 
-![.NET Core project with existing project in different folder][example-csproj-different-folder]
+![.NET Core project with existing project in different folder](media/project-structure/project.csproj.different.png)
 
-[**Source Code**][example-csproj-different-code]
+[**Source Code**](https://github.com/dotnet/samples/tree/master/framework/libraries/migrate-library-csproj-keep-existing/)
 
 Changes to note are:
 
@@ -63,18 +63,4 @@ Changes to note are:
 
 ## See also
 
-Please see the [.NET Core porting documentation][porting-doc] for more guidance on migrating to .NET Core.
-
-[porting-doc]: index.md
-[example-initial-project]: media/project-structure/project.png "Existing project"
-[example-initial-project-code]: https://github.com/dotnet/samples/tree/master/framework/libraries/migrate-library/
-
-[example-csproj]: media/project-structure/project.csproj.png "Create a csproj that targets multiple frameworks"
-[example-csproj-code]: https://github.com/dotnet/samples/tree/master/framework/libraries/migrate-library-csproj/
-[example-csproj-netcore]: https://github.com/dotnet/samples/tree/master/framework/libraries/migrate-library-csproj/src/Car/Car.csproj
-
-[example-csproj-different-folder]: media/project-structure/project.csproj.different.png ".NET Core project with existing PCL in different folder"
-[example-csproj-different-code]: https://github.com/dotnet/samples/tree/master/framework/libraries/migrate-library-csproj-keep-existing/
-
-[option-csproj]: #replace-existing-projects-with-a-multi-targeted-net-core-project
-[option-csproj-folder]: #keep-existing-projects-and-create-a-net-core-project
+Please see the [.NET Core porting documentation](index.md) for more guidance on migrating to .NET Core.

docs/core/tools/global-tools-how-to-create.md

@@ -8,7 +8,7 @@ ms.date: 08/22/2018
 
 # Create a .NET Core Global Tool using the .NET Core CLI
 
-This article teaches you how to create and package a .NET Core Global Tool. The .NET Core CLI allows you to create a console application as a Global Tool, which others can easily install and run. .NET Core Global Tools are NuGet packages that are installed from the .NET Core CLI. For more information about Global Tools, see [.NET Core Global Tools overview][global-tool-info].
+This article teaches you how to create and package a .NET Core Global Tool. The .NET Core CLI allows you to create a console application as a Global Tool, which others can easily install and run. .NET Core Global Tools are NuGet packages that are installed from the .NET Core CLI. For more information about Global Tools, see [.NET Core Global Tools overview](global-tools.md).
 
 [!INCLUDE [topic-appliesto-net-core-21plus.md](../../../includes/topic-appliesto-net-core-21plus.md)]
 
@@ -165,7 +165,7 @@ Now that you have a package, install the tool from that package:
 dotnet tool install --global --add-source ./nupkg botsay
 ```
 
-The `--add-source` parameter tells the .NET Core CLI to temporarily use the `./nupkg` folder (our `<PackageOutputPath>` folder) as an additional source feed for NuGet packages. For more information about installing Global Tools, see [.NET Core Global Tools overview][global-tool-info].
+The `--add-source` parameter tells the .NET Core CLI to temporarily use the `./nupkg` folder (our `<PackageOutputPath>` folder) as an additional source feed for NuGet packages. For more information about installing Global Tools, see [.NET Core Global Tools overview](global-tools.md).
 
 If installation is successful, a message is displayed showing the command used to call the tool and the version installed, similar to the following example:
 
@@ -186,5 +186,3 @@ Once you're done experimenting with the tool, you can remove it with the followi
 ```console
 dotnet tool uninstall -g botsay
 ```
-
-[global-tool-info]: global-tools.md

docs/framework/tools/ngen-exe-native-image-generator.md

@@ -44,7 +44,7 @@ The Native Image Generator (Ngen.exe) is a tool that improves the performance of
 
  On Windows 8, see [Native Image Task](#native-image-task).  
 
- For additional information on using Ngen.exe and the native image service, see [Native Image Service][Native Image Service].  
+ For additional information on using Ngen.exe and the native image service, see [Native Image Service](#native-image-service).  
 
 > [!NOTE]
 >  Ngen.exe syntax for versions 1.0 and 1.1 of the .NET Framework can be found in [Native Image Generator (Ngen.exe) Legacy Syntax](https://msdn.microsoft.com/library/5a69fc7a-103f-4afc-8ab4-606adcb46324).  
@@ -90,7 +90,7 @@ ngen /? | /help
 |--------------|-----------------|  
 |`1`|Native images are generated and installed immediately, without waiting for idle time.|  
 |`2`|Native images are generated and installed without waiting for idle time, but after all priority 1 actions (and their dependencies) have completed.|  
-|`3`|Native images are installed when the native image service detects that the computer is idle. See [Native Image Service][Native Image Service].|  
+|`3`|Native images are installed when the native image service detects that the computer is idle. See [Native Image Service](#native-image-service).|  
 
 <a name="ScenarioTable"></a>   
 ## Scenarios  
@@ -307,7 +307,7 @@ using namespace System::Runtime::CompilerServices;
 
 <a name="Deferred"></a>   
 ## Deferred processing  
- Generation of native images for a very large application can take considerable time. Similarly, changes to a shared component or changes to computer settings might require many native images to be updated. The `install` and `update` actions have a `/queue` option that queues the operation for deferred execution by the native image service. In addition, Ngen.exe has `queue` and `executeQueuedItems` actions that provide some control over the service. For more information, see [Native Image Service][Native Image Service].  
+ Generation of native images for a very large application can take considerable time. Similarly, changes to a shared component or changes to computer settings might require many native images to be updated. The `install` and `update` actions have a `/queue` option that queues the operation for deferred execution by the native image service. In addition, Ngen.exe has `queue` and `executeQueuedItems` actions that provide some control over the service. For more information, see [Native Image Service](#native-image-service).  
 
 <a name="JITCompilation"></a>   
 ## Native images and JIT compilation  
@@ -464,7 +464,7 @@ ngen display "myAssembly, version=1.0.0.0"
 ngen update  
 ```  
 
- Updating all images can be a lengthy process. You can queue the updates for execution by the native image service by using the `/queue` option. For more information on the `/queue` option and installation priorities, see [Native Image Service][Native Image Service].  
+ Updating all images can be a lengthy process. You can queue the updates for execution by the native image service by using the `/queue` option. For more information on the `/queue` option and installation priorities, see [Native Image Service](#native-image-service).  
 
 ```  
 ngen update /queue  
@@ -505,7 +505,7 @@ ngen uninstall "ClientApp, Version=1.0.0.0, Culture=neutral,
 
  As with the `install` action, supplying an extension requires either executing Ngen.exe from the directory containing the assembly or specifying a full path.  
 
- For examples relating to the native image service, see [Native Image Service][Native Image Service].  
+ For examples relating to the native image service, see [Native Image Service](#native-image-service).  
 
 ## Native Image Task  
  The native image task is a Windows task that generates and maintains native images. The native image task generates and reclaims native images automatically for supported scenarios. (See [Creating Native Images](https://msdn.microsoft.com/library/2bc8b678-dd8d-4742-ad82-319e9bf52418).) It also enables installers to use [Ngen.exe (Native Image Generator)](../../../docs/framework/tools/ngen-exe-native-image-generator.md) to create and update native images at a deferred time.  
@@ -517,7 +517,7 @@ ngen uninstall "ClientApp, Version=1.0.0.0, Culture=neutral,
 |NET Framework NGEN v4.0.30319|Yes|Yes|  
 |NET Framework NGEN v4.0.30319 64|No|Yes|  
 
- The native image task is available in the .NET Framework 4.5 and later versions, when running on Windows 8 or later. On earlier versions of Windows, the .NET Framework uses the [Native Image Service][Native Image Service].  
+ The native image task is available in the .NET Framework 4.5 and later versions, when running on Windows 8 or later. On earlier versions of Windows, the .NET Framework uses the [Native Image Service](#native-image-service).  
 
 ### Task Lifetime  
  In general, the Windows Task Scheduler starts the native image task every night when the computer is idle. The task checks for any deferred work that is queued by application installers, any deferred native image update requests, and any automatic image creation. The task completes outstanding work items and then shuts down. If the computer stops being idle while the task is running, the task stops.  
@@ -583,5 +583,3 @@ ngen executeQueuedItems
 - [Managed Execution Process](../../../docs/standard/managed-execution-process.md)
 - [How the Runtime Locates Assemblies](../../../docs/framework/deployment/how-the-runtime-locates-assemblies.md)
 - [Command Prompts](../../../docs/framework/tools/developer-command-prompt-for-vs.md)
-
-[Native Image Service]: #native-image-service