Merge pull request NuGet#162 from NuGet/kraigb

Adding more code tags and other corrections

Author: Kraig Brockschmidt

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

@@ -63,10 +63,12 @@ The preferred method for changing the configuration is using the NuGet [config c
 
 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/Managing-the-NuGet-Cache.md

@@ -35,22 +35,26 @@ NuGet manages several local caches to avoid downloading packages that are alread
 
 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/Package-References-in-Project-Files.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-Restore.md

@@ -118,9 +118,11 @@ For NuGet 2.6 and earlier, you use the [Install](../tools/nuget.exe-cli-referenc
 
 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/Team-Foundation-Build.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/Create-Packages/Creating-a-Package.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.
@@ -361,20 +375,26 @@ 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/Publish-a-package.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/Symbol-Packages.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.

docs/Create-Packages/project.json-and-UWP.md

@@ -85,11 +85,7 @@ NuGet packages using the new format have the following well-known directories an
 
 ## MSBuild targets and props files in packages
 
-NuGet packages can contain .props and .targets files which will be imported into any MSBuild project that the package is installed into. In NuGet 2.x, this was done by injecting <Import> statements into the .csproj file, in NuGet 3.0 there is no specific "installation to project" action. Instead the package restore process writes two files:
-
-* [projectname].nuget.props
-
-* [projectname].nuget.targets
+NuGet packages can contain .props and .targets files which will be imported into any MSBuild project that the package is installed into. In NuGet 2.x, this was done by injecting <Import> statements into the .csproj file, in NuGet 3.0 there is no specific "installation to project" action. Instead the package restore process writes two files `[projectname].nuget.props` and `[projectname].nuget.targets`.
 
 MSBuild knows to look for these two files and automatically imports them near the beginning and near the end of the project build process. This provides very similar behavior to NuGet 2, but with one major difference: **There is no guaranteed order of targets/props files in this case**. However, MSBuild does provide ways to order Targets through the BeforeTargets and AfterTargets attributes of the <Target> definition (see [https://msdn.microsoft.com/en-us/library/t50z2hka.aspx](https://msdn.microsoft.com/en-us/library/t50z2hka.aspx)).
 

docs/Guides/Create-Cross-Platform-Packages.md

@@ -124,7 +124,9 @@ To implement a platform-specific implementation of the `ILoggingLibrary` interfa
 
 1. Open a command prompt, navigate to the `LoggingLibrary` folder that's one level below where the .sln file is, and run the NuGet `spec` command to create the initial `Package.nuspec` file:
 
+```bash
         nuget spec
+```
 
 1. Rename this file to `LoggingLibrary.nuspec` and open it in an editor.
 1. Update the file to match the following, replacing YOUR_NAME with an appropriate value. The <id> value, specifically, must be unique across nuget.org (see the naming conventions described in [Creating a package](../create-packages/creating-a-package.md#choosing-a-unique-package-identifier-and-setting-the-version-number)). Also note that you must also update the author and description tags or you'll get an error during the packing step.
@@ -263,7 +265,9 @@ Your final .nuspec file should now look like the following, where again YOUR_NAM
 
 With the completed .nuspec referencing all the files you need to include in the package, you're ready to run the `pack` command:
 
+```bash
     nuget pack LoggingLibrary.nuspec
+```
 
 This will generate `LoggingLibrary.YOUR_NAME.1.0.0.nupkg`. Opening this file in a tool like the [NuGet Package Explorer](https://github.com/NuGetPackageExplorer/NuGetPackageExplorer) and expanding all the nodes, you'll see the following contents:
 

docs/Guides/Create-NET-Standard-Packages-VS2015.md

@@ -89,7 +89,9 @@ This guide will walk you through creating a nuget package targeting .NET Standar
 
 1. Open a command prompt, navigate to the folder containing `AppLogg.csproj` folder (one level below where the .sln file is), and run the NuGet `spec` command to create the initial `AppLogger.nuspec` file:
 
+```bash
         nuget spec
+```
 
 1. Open `AppLogger.nuspec` in an editor and update it to match the following, replacing YOUR_NAME with an appropriate value. The <id> value, specifically, must be unique across nuget.org (see the naming conventions described in [Creating a package](../create-packages/creating-a-package.md#choosing-a-unique-package-identifier-and-setting-the-version-number). Also note that you must also update the author and description tags or you'll get an error during the packing step.
 
@@ -128,7 +130,9 @@ This guide will walk you through creating a nuget package targeting .NET Standar
 
 With the completed .nuspec referencing all the files you need to include in the package, you're ready to run the `pack` command:
 
+```bash
     nuget pack AppLogger.nuspec
+```
 
 This will generate `AppLogger.YOUR_NAME.1.0.0.nupkg`. Opening this file in a tool like the [NuGet Package Explorer](https://github.com/NuGetPackageExplorer/NuGetPackageExplorer) and expanding all the nodes, you'll see the following contents:
 

docs/Guides/Create-UWP-Packages.md

@@ -80,7 +80,9 @@ To create the initial .nuspec file, do the three steps below. The sections that
 1. Open a command prompt and navigate to the folder containing ImageEnhancer.vcxproj (this will be a subfolder below where the solution file is).
 1. Run the NuGet `spec` command to generate `ImageEnhancer.nuspec` (the name of the file is taken from the name of the .vcxproj file):
 
+    ```bash
         nuget spec
+    ```
 
 1. Open `ImageEnhancer.nuspec` in an editor and update it to match the following, replacing YOUR_NAME with an appropriate value. The <id> value, specifically, must be unique across nuget.org (see the naming conventions described in [Creating a package](../create-packages/creating-a-package.md#choosing-a-unique-package-identifier-and-setting-the-version-number)). Also note that you must also update the author and description tags or you'll get an error during the packing step.
 
@@ -259,7 +261,9 @@ Your final .nuspec file should now look like the following, where again YOUR_NAM
 
 With the completed .nuspec referencing all the files you need to include in the package, you're ready to run the `pack` command:
 
+```bash
     nuget pack ImageEnhancer.nuspec
+```
 
 This will generate `ImageEnhancer.YOUR_NAME.1.0.0.nupkg`. Opening this file in a tool like the [NuGet Package Explorer](https://github.com/NuGetPackageExplorer/NuGetPackageExplorer) and expanding all the nodes, you'll see the following contents:
 

docs/Guides/Install-NuGet.md

@@ -70,8 +70,10 @@ The NuGet CLI can be installed using any of the following methods:
 
 1. **Chocolatey**: Install the [NuGet.CommandLine](http://chocolatey.org/packages/NuGet.CommandLine) Chocolatey package using the [Chocolatey](http://chocolatey.org) client. 
 
+    ```bash
         choco install nuget.commandline
-
+    ```
+    
 1. **Visual Studio**: Install the [NuGet.CommandLine](http://www.nuget.org/packages/NuGet.CommandLine/) package from the Package Manager Console in Visual Studio.
 
 > **NuGet 2.x users**