Merge branch 'master' of https://github.com/NuGet/docs.microsoft.com-nuget

Author: BuildTools

docs/API/NuGet-Credential-Providers-for-Visual-Studio.md

@@ -38,7 +38,7 @@ A sample implementation can be found in [the VsCredentialProvider sample](https:
 > [!Note]
 > NuGet credential providers for Visual Studio must be installed as a regular Visual Studio extension and will require [Visual Studio 2017](https://aka.ms/vs/15/preview/vs_enterprise) (currently in preview) or above.
 >
-> NuGet credential providers for Visual Studio work only in Visual Studio (not in dotnet restore or nuget.exe). For credential providers with nuget.exe, see [NuGet.exe Credential Providers](../api/nuget.exe-credential-providers.md).
+> NuGet credential providers for Visual Studio work only in Visual Studio (not in dotnet restore or nuget.exe). For credential providers with nuget.exe, see [NuGet.exe Credential Providers](../api/nuget-exe-Credential-providers.md).
 
 ## Available NuGet credential providers for Visual Studio
 

docs/API/NuGet.exe-Credential-Providers.md renamed to docs/API/nuget-exe-Credential-Providers.md

@@ -54,19 +54,21 @@ The behavior of every NuGet command, whether issued from the command line, the P
 
 ## Changing config settings
 
-A configuration file is a simple XML text file containing settings as described in the [NuGet Configuration Settings](../schema/nuget.config-file.md) topic.
+A configuration file is a simple XML text file containing settings as described in the [NuGet Configuration Settings](../Schema/nuget-config-file.md) topic.
 
-The preferred method for changing the configuration is using the NuGet [config command](../tools/nuget.exe-cli-reference.md#config) to set a key and value.
+The preferred method for changing the configuration is using the NuGet [config command](../tools/nuget-exe-cli-reference.md#config) to set a key and value.
 
 > [!Note]
 > Keys are always case sensitive.
 
 To **set a value** in any existing configuration file, use the `-configFile` switch as shown in the examples below.
 
+```bash
     nuget config -set repositoryPath=c:\packages -configfile c:\my.config
     nuget config -set repositoryPath=c:\packages -configfile .\myApp\NuGet.Config
     nuget config -set repositoryPath=c:\packages -configfile %ProgramData%\NuGet\Config\VisualStudio\14.0\NuGet.Config
     nuget config -set repositoryPath=c:\packages -configfile %ProgramData%\NuGet\NuGetDefaults.Config
+```
 
 Without the `-configFile` switch, NuGet will make the change in the global config file.
 
@@ -75,7 +77,9 @@ Without the `-configFile` switch, NuGet will make the change in the global confi
 
 To **remove a value**, use the same commands but with an empty value, such as:
 
+```bash
     nuget config -set repositoryPath= -configfile c:\my.config
+```
 
 To create a new configuration file, copy the template below into that file and then use the `nuget config --configFile <filename>` command to set values:
 

docs/Consume-Packages/Configuring-NuGet-Behavior.md

@@ -33,24 +33,28 @@ ms.reviewer:
 
 NuGet manages several local caches to avoid downloading packages that are already on the machine, and to provide offline support. NuGet versions 2.8 and later automatically fall back to the cache when installing or reinstalling packages without a network connection.
 
-To see the list of cache locations, use the [locals command](../tools/nuget.exe-cli-reference.md#locals):
+To see the list of cache locations, use the [locals command](../tools/nuget-exe-cli-reference.md#locals):
 
+```bash
     nuget locals all -list
+```
 
 Typical output is as follows:
 
-    http-cache: C:\Users\kraigb\AppData\Local\NuGet\v3-cache   #3.x cache
-    packages-cache: C:\Users\kraigb\AppData\Local\NuGet\Cache  #2.x cache
-    global-packages: C:\Users\kraigb\.nuget\packages\          #Global cache
-    temp: C:\Users\kraigb\AppData\Local\Temp\NuGetScratch      #Temp folder
+    http-cache: C:\Users\user\AppData\Local\NuGet\v3-cache   #3.x cache
+    packages-cache: C:\Users\user\AppData\Local\NuGet\Cache  #2.x cache
+    global-packages: C:\Users\user\.nuget\packages\          #Global cache
+    temp: C:\Users\user\AppData\Local\Temp\NuGetScratch      #Temp folder
 
 If you encounter package installation problems or otherwise want to ensure that you're installing packages from the remote gallery, use the `locals -clear` option in one or more of the following ways:
 
+```bash
     nuget locals http-cache -clear        #Clear the 3.x cache
     nuget locals packages-cache -clear    #Clear the 2.x cache
     nuget locals global-packages -clear   #Clear the global cache
     nuget locals temp -clear              #Clear the temporary cache
     nuget locals all -clear               #Clears all caches
+```
 
 Note that managing the cache is presently supported only from the NuGet command line, and not within Visual Studio or through the Package Manager Console. Also, managing the 2.x cache is not supported in NuGet 3.6 and later.
 

docs/Consume-Packages/Managing-the-NuGet-Cache.md

@@ -34,7 +34,7 @@ Between nuget.org and private package galleries that your organization might est
 
 ![Flow of going to a package source, finding a package, installing it in a project, then adding a using statement and calls to the package API](media/Overview-01-GeneralFlow.png)
 
-\* _Except with `nuget install` from the command-line, in which case it's necessary to edit the configuration files by hand. See the [install command reference](../tools/nuget.exe-cli-reference.md#install)._
+\* _Except with `nuget install` from the command-line, in which case it's necessary to edit the configuration files by hand. See the [install command reference](../tools/nuget-exe-cli-reference.md#install)._
 
 NuGet remembers the identity and version number of each installed package, recording it in either `packages.config` or `project.json` in your project root, depending on project type. With NuGet 4.0+ and .NET Core projects, dependencies are instead stored in the project file directly. See [Package References in Project Files](../consume-packages/package-references-in-project-files.md). In any case, you can look in the appropriate file at any time to see the full list of  dependencies for your project.
 

docs/Consume-Packages/Overview-and-Workflow.md

@@ -110,23 +110,25 @@ You might be using a dependency purely as a development harness and might not wa
 
 The following metadata tags control dependency assets:
 
-| Tag | Description | Default Value
-| IncludeAssets | These assets will be consumed | all
-| ExcludeAssetsTag | These assets will not be consumed | none
-| PrivateAssets | These assets will be consumed but won't flow to the parent project | contentfiles;analyzers;build
+Tag | Description | Default Value
+--- | --- | ---
+IncludeAssets | These assets will be consumed | all
+ExcludeAssetsTag | These assets will not be consumed | none
+PrivateAssets | These assets will be consumed but won't flow to the parent project | contentfiles;analyzers;build
 
 
 Allowable values for these tags are as follows, with multiple values separated by a semicolon except with `all` and `none` which must appear by themselves:
 
-| Value | Description
-| compile | Contents of the `lib` folder
-| runtime | Contents of the `runtime` folder
-| contentFiles | Contents of the `contentfiles` folder
-| build | Props and targets in the `build` folder
-| anaylzers | .NET analyzers
-| native | Contents of the `native` folder
-| none | None of the above are used.
-| all | All of the above (except `none`)
+Value | Description
+--- | ---
+compile | Contents of the `lib` folder
+runtime | Contents of the `runtime` folder
+contentFiles | Contents of the `contentfiles` folder
+build | Props and targets in the `build` folder
+anaylzers | .NET analyzers
+native | Contents of the `native` folder
+none | None of the above are used.
+all | All of the above (except `none`)
 
 In the following example, everything except the content files from the package would be consumed by the project and everything except content files and analyzers would flow to the parent project.
 

docs/Consume-Packages/Package-References-in-Project-Files.md

@@ -87,7 +87,7 @@ Package restore is primarily enabled through **Tools > Options > [NuGet] Package
         </configuration>
     ```
 
-For reference, see the [NuGet config file - packageRestore section](../schema/nuget.config-file.md#packagerestore-section).
+For reference, see the [NuGet config file - packageRestore section](../Schema/nuget-config-file.md#packagerestore-section).
 
 MSBuild-integrated restore with NuGet 2.6 and earlier is typically enabled by right-clicking a solution in Visual Studio and selecting **Enable NuGet Package Restore**. This sets up the necessary files and folders for this option to work, as explained under [MSBuild-integrated restore in Visual Studio](#msbuild-integrated-restore).
 
@@ -114,13 +114,15 @@ In both cases, use the notation described in [Dependency versions](../create-pac
 
 ## Command-line restore
 
-For NuGet 2.6 and earlier, you use the [Install](../tools/nuget.exe-cli-reference.md#install) command and point to the `packages.config` file that lists all the dependencies.
+For NuGet 2.6 and earlier, you use the [Install](../tools/nuget-exe-cli-reference.md#install) command and point to the `packages.config` file that lists all the dependencies.
 
-For NuGet 2.7 and above, use the [Restore](../tools/nuget.exe-cli-reference.md#restore) command to restore all packages in a solution (using either `packages.config` in NuGet 2.x and later or `project.json` in NuGet 3.x and later). For a given project folder such as `c:\proj\app`, the common variations below each restore the packages:
+For NuGet 2.7 and above, use the [Restore](../tools/nuget-exe-cli-reference.md#restore) command to restore all packages in a solution (using either `packages.config` in NuGet 2.x and later or `project.json` in NuGet 3.x and later). For a given project folder such as `c:\proj\app`, the common variations below each restore the packages:
 
+```bash
     c:\proj\app\> nuget restore
     c:\proj\app\> nuget.exe restore app.sln
     c:\proj\> nuget restore app
+```
 
 ## Automatic restore in Visual Studio
 
@@ -149,8 +151,10 @@ To correct these errors, do one of the following:
 1. [Migrate the project to automatic restore](#migrating-to-automatic-restore).
 1. Update `nuget.exe` in the `.nuget` folder** as follows
 
+    ```bash
         cd .nuget
         nuget update -self
+    ```
 
 1. Reset consent in your `%AppData%\NuGet\NuGet.config` file by going to **Tools > Options > NuGet Package Manager > General** in Visual Studio, uncheck and re-check both **Package Restore** options, and click OK. This re-saves `NuGet.config` with the proper consent settings for NuGet 2.6 and earlier.
 

docs/Consume-Packages/Package-Restore.md

@@ -73,7 +73,7 @@ To disable source control integration with TFVC for selected files:
 1. Create a folder called `.nuget` in your solution folder (where the `.sln` file is).
     * Tip: on Windows, to create this folder in Windows Explorer, use the name `.nuget.` *with* the training dot.
 1. In that folder, create a file named `NuGet.config` and open it for editing.
-1. Add the following text as a minimum, where the [disableSourceControlIntegration](../schema/nuget.config-file.md#solution-section) setting instructs Visual Studio to skip everything in the `packages` folder:
+1. Add the following text as a minimum, where the [disableSourceControlIntegration](../Schema/nuget-config-file.md#solution-section) setting instructs Visual Studio to skip everything in the `packages` folder:
 
     ```xml
         <?xml version="1.0" encoding="utf-8"?>

docs/Consume-Packages/Packages-and-Source-Control.md

@@ -52,7 +52,9 @@ NuGet has supported [restoring packages](../consume-packages/package-restore.md)
 
 The cure to this problem is making sure that packages are restored as the first step in the build process. NuGet 2.7+ makes this easy via a simplified command line:
 
+```bash
     nuget restore path\to\solution.sln
+```
 
 When your build process restores packages before building the code, you don't need to check-in **.targets** files
 

docs/Consume-Packages/Team-Foundation-Build.md

@@ -128,7 +128,9 @@ For details on declaring dependencies and specifying version numbers, see [Depen
 
 Because the manifest is always included in a package, you can find any number of additional examples by examining existing packages. A good source is the global package cache on your machine, the location of which is returned by the following command:
 
+```bash
     nuget locals -list global-packages
+```
 
 Go into any *package\version* folder, copy the .nupkg file to a .zip file, then open that .zip file and examine the .nuspec within it.
 
@@ -139,7 +141,9 @@ Note that when creating a `.nuspec` from a Visual Studio project, the manifest w
 
 You can create a `.nuspec` file from scratch in any text editor, or by editing a file from another project. You can also have NuGet create a template manifest for your by using the following command:
 
+```bash
     nuget spec <package_name>
+```
 
 The resulting `<package_name>.nuspec` file (or `Package.nuspec` if you omit a specific name) will contain placeholders for values like the `projectUrl`, so be sure to edit it before using it to creating the package.
 
@@ -149,13 +153,17 @@ You can also use `nuget spec` with an existing assembly, a Visual Studio project
 
 If you have an assembly DLL, you can easily generate a `.nuspec` file from the metadata in the assembly using the following command:
 
+```bash
     nuget spec MyAssembly.dll
+```
 
 ### From a Visual Studio project
 
 Creating a `.nuspec` from a `.csproj` or `.vbproj` file is convenient because other packages that have been installed into those project will be automatically referenced as dependencies. Simply use the following command in the same folder as the project file:
 
+```bash
     nuget spec
+```
 
 This creates a template `<project_name>.nuspec` file as usual, but includes tokens that will be replaced at packaging time with values from the project. This means you do not need to update crucial values like the version number in the `.nuspec` as you update the project (but you can always replace the tokens with literal values, if desired).
 
@@ -200,7 +208,9 @@ Think of the **content** folder as the root of the target application, so if you
 
 Next, from the root folder of this layout, run the following command to create the `.nuspec` file:
 
+```bash
     nuget spec
+```
 
 In this case, the `.nuspec` will not contain any explicit references to the folder structure, but all those files will be automatically included when creating the package later on.
 
@@ -333,11 +343,15 @@ With NuGet 3.x, targets are not added to the project but are instead made availa
 
 When using an assembly or the convention-based working directory, create a package by running `nuget pack` with your `.nuspec` file:
 
+```bash
     nuget pack &lt;your_project&gt;.nuspec
+```
 
 When using a Visual Studio project, run `nuget pack` instead with your project file, which will automatically load the project's `.nuspec` file and replace any tokens within it using values in the project file:
 
+```bash
     nuget pack &lt;your_project&gt;.csproj
+```
 
 > [!Note]
 > Using the project file directly is necessary for token replacement because the project is the source of the token values. Token replacement does not happen if you use `nuget pack` with a `.nuspec` file.
@@ -355,26 +369,32 @@ Once `nuget pack` succeeds, you'll have a `.nupkg` file that you can publish to
 
 ### Additional options
 
-You can use various command-line switches with `nuget pack` to exclude files, override the version number in the manifest, and change the output directory, among other features. For a complete list, refer to the [pack command reference](../tools/nuget.exe-cli-reference.md#pack).
+You can use various command-line switches with `nuget pack` to exclude files, override the version number in the manifest, and change the output directory, among other features. For a complete list, refer to the [pack command reference](../tools/nuget-exe-cli-reference.md#pack).
 
 The following options are a few that are common with Visual Studio projects:
 
 - **Referenced projects**: If the project references other projects, you can add the referenced projects as part of the package, or as dependencies, by using the `-IncludeReferencedProjects` option:
 
+    ```bash
         nuget pack MyProject.csproj -IncludeReferencedProjects
+    ```
 
     This inclusion process is recursive, so if MyProject.csproj references projects B and C, and those projects reference D, E, and F, then files from B, C, D, E, and F will be included in the package.
 
     If a referenced project includes a `.nuspec` file of its own, then NuGet adds that referenced project as a dependency instead.  You will need to package and publish that project separately.
 
 - **Build configuration**: By default, NuGet will use the default build configuration set in the project file, typically *Debug*. To pack files from a different build configuration, such as *Release*, use the `-properties` option with the configuration:
 
+    ```bash
         nuget pack MyProject.csproj -properties Configuration=Release
+    ```
 
 - **Symbols**: to include symbols that allow consumers to step through your package code in the debugger, use the `-Symbols` option:
 
+    ```bash
         nuget pack MyProject.csproj -symbols
-
+    ```
+    
 ## Next Steps
 
 Once you've created a package, which is a `.nupkg` file, you can publish it to the gallery of your choice as described on [Publishing a Package](../create-packages/publish-a-package.md).

docs/Create-Packages/Creating-a-Package.md

@@ -72,7 +72,7 @@ By default, NuGet does not include pre-release versions when working with packag
 
 - **Package Manager Console**: Use the `-IncludePrerelease` switch with the `Find-Package`, `Get-Package`, `Install-Package`, `Sync-Package`, and `Update-Package` commands. Refer to the [PowerShell Reference](../tools/powershell-reference.md).
 
-- **NuGet CLI**: Use the `-prerelease` switch with the `install`, `update`, `delete`, and `mirror` commands. Refer to the [NuGet CLI reference](../tools/nuget.exe-cli-reference.md)
+- **NuGet CLI**: Use the `-prerelease` switch with the `install`, `update`, `delete`, and `mirror` commands. Refer to the [NuGet CLI reference](../tools/nuget-exe-cli-reference.md)
 
 
 ## Semantic versioning

docs/Create-Packages/Prerelease-Packages.md

@@ -54,13 +54,17 @@ Next, you can either upload the package through the nuget.org web portal, or pus
 
     3. At a command prompt, run the following command:
 
+        ```bash
             nuget setApiKey Your-API-Key
+        ```
 
         This will store your API key on the machine so that you will not need to do this step again on the same machine.
 
     4. Push your package to NuGet Gallery using the command:
 
+        ```bash
             nuget push YourPackage.nupkg -Source https://www.nuget.org/api/v2/package
+        ```
 
     5. Before being made public, all packages uploaded to nuget.org are scanned for viruses and rejected if any viruses are found. All packages listed on nuget.org are also scanned periodically.
 

docs/Create-Packages/Publish-a-package.md

@@ -43,9 +43,11 @@ To create a symbol package, follow these conventions:
 
 You can create both packages with the `-Symbols` option, either from a nuspec file or a project file:
 
+```bash
     nuget pack MyPackage.nuspec -Symbols
 
     nuget pack MyProject.csproj -Symbols
+```
 
 Note that `pack` requires Mono 4.4.2 on Mac OS X and does not work on Linux systems. On a Mac, you must also convert Windows pathnames in the `.nuspec` file to Unix-style paths.
 
@@ -110,18 +112,26 @@ A symbol package can be built by conventions, from a folder structure as describ
 
 1. For convenience, first save your API key with NuGet (see [publish a package](../create-packages/publish-a-package.md), which will apply to both nuget.org and symbolsource.org, because symbolsource.org will check with nuget.org to verify that you are the package owner.
 
+```bash
     nuget SetApiKey Your-API-Key
+```
 
 1. After publishing your primary package to nuget.org, push the symbol package as follows, which will automatically use symbolsource.org as the target because of the `.symbols` in the filename:
 
+```bash
     nuget push MyPackage.symbols.nupkg
+```
 
 1. To publish to a different symbol repository, or to push a symbol package that doesn't follow the naming convention, use the `-Source` option:
 
+```bash
     nuget push MyPackage.symbols.nupkg -source https://nuget.smbsrc.net/
+```
 
 1. You can also push both primary and symbol packages to both repositories at the same time using the following:
 
+```bash
     nuget push MyPackage.nupkg
+```
 
     In this case, NuGet will publish `MyPackage.symbols.nupkg`, if present, to symbolsource.org (https://nuget.smbsrc.net/), after it publishes the primary package to nuget.org.