anchor.diff:      $ cf push MY-APP -b https://github.com/cloudfoundry/dotnet-core-buildpack.git
       </pre>
   
  -1. Find the URL of your app in the output from the push command and navigate to it to see your app running.  In the example above, `my-app.example.com` is the URL of your app.
  +1. Find the URL of your app in the output from the push command and navigate to it to see your HWC app running.  In the example above, `my-app.example.com` is the URL of your app.
   
   For a basic example app, see [ASP.NET Core getting started application](https://github.com/IBM-Bluemix/aspnet-core-helloworld) in GitHub.
   
  -## <a id='source-based'></a>Source-Based, Non-Published Deployments
  -
  -To use this workflow, push the source code for your app, not the output directory of the `dotnet publish` command,
  -to Cloud Foundry by running the `cf push` command.
  -
  -The source-based, non-published workflow ensures the buildpack can keep all your dependencies in sync and up to date.
  -For additional information about using this workflow, see the following sections:
  -
  -* [Deploy Apps with Multiple Projects](#multiple-projects)
  -* [Use Non-Default Package Sources](#non-default-package-sources)
  -* [Disable and Clear the NuGet Package Cache](#disabling-nuget)
  +## <a id='source-based'></a>Source-based, Non-published Workflow
  +
  +To use this workflow, simply `cf push` the source code for your app (i.e. not the resultant directory of a `dotnet publish`).
  +
  +This is the recommended workflow because the buildpack can keep all your dependencies in-sync and up-to-date.
  +When using this workflow, here are some edge-cases you may run into:
   
   ### <a id='multiple-projects'></a>Deploy Apps with Multiple Projects
   
  -If you want to deploy an app that contains multiple projects, you must specify your main project for the buildpack to run.
  -Create a `.deployment` file in the root folder of the app that sets the path to the main project as follows:
  +To deploy an app that contains multiple projects, you must specify a main project for the buildpack to run. Create a `.deployment` file in the root folder of the app which sets the path to the main project as follows:
   
   ```text
   [config]
  -project = PATH-TO-YOUR-MAIN-PROJECT
  -```
  -
  -Where `PATH-TO-YOUR-MAIN-PROJECT` is the location of your main project.
  -Set `project` to the `*.csproj` or `*.fsproj` file of the main project.
  -
  -For example, if an app contains three projects in the `src` folder,
  -the main project `MyApp.Web` as well as `MyApp.DAL` and `MyApp.Services`,
  -format the `.deployment` file as follows:
  +project = <main project>
  +```
  +
  +1. Set `project` to the `*.csproj` or `*.fsproj` file of the main project.
  +
  +For example, if an app contains three projects in the `src` folder (the main project `MyApp.Web`, `MyApp.DAL`, and `MyApp.Services`), format the `.deployment` file as follows:
   
   ```text
   [config]
   project = src/MyApp.Web/MyApp.Web.csproj
   ```
   
  -In this example, the buildpack automatically compiles the `MyApp.DAL` and `MyApp.Services` projects
  -if the `MyApp.Web.csproj` file of the main project lists them as dependencies.
  -The buildpack attempts to execute the main project with `dotnet run -p src/MyApp.Web/MyApp.Web.csproj`.
  -
  -### <a id='non-default-package-sources'></a>Use Non-Default Package Sources
  -
  -If you want to deploy an app that uses non-default package sources,
  -you must specify those package sources in the `NuGet.Config` file.
  -For information about `NuGet.Config`,
  -see [nuget.config reference](https://docs.microsoft.com/en-us/nuget/reference/nuget-config-file)
  -in the Microsoft documentation.
  -For a basic example of a .NET Core app,
  -see the [aspnet-core-helloworld](https://github.com/IBM-Bluemix/aspnet-core-helloworld) repository on GitHub.
  -
  -### <a id='disabling-nuget'></a>Disable and Clear the NuGet Package Cache
  -
  -You may need to disable NuGet package caching or clear NuGet packages cached in the staging environment
  -in one of the following scenarios:
  +In this example, the buildpack automatically compiles the `MyApp.DAL` and `MyApp.Services` projects if the `MyApp.Web.csproj` file of the main project lists them as dependencies. The buildpack attempts to execute the main project with `dotnet run -p src/MyApp.Web/MyApp.Web.csproj`.
  +
  +### <a id='non-default-package-sources'></a>Using Non-Default Package Sources
  +
  +To deploy an app that uses non-default package sources, you must specify those package sources in the [`NuGet.Config` file](https://docs.microsoft.com/en-us/nuget/reference/nuget-config-file).
  +For a basic example, see this [Hello World sample](https://github.com/IBM-Bluemix/aspnet-core-helloworld).
  +
  +### <a id='disabling-nuget'></a>Disabling and Clearing the NuGet Package Cache
  +
  +You may need to disable NuGet package caching, or clear NuGet packages cached in the staging environment, in one of the following scenarios:
   
   * Your app fails to stage because it runs out of space, exceeding the maximum allowable disk quota.
  -* You have added pre-release packages to test a new feature, and then decided to revert back to the main NuGet feed.
  -You may need to remove the packages you changed from the cache to avoid conflicts.
  -
  -Disabling NuGet caching clears any existing NuGet dependencies from the staging cache
  -and prevents the buildpack from adding NuGet dependencies to the staging cache.
  -To disable NuGet package caching, set the `CACHE_NUGET_PACKAGES` environment variable to `false`.
  -If the variable is not set, no change is required.
  -
  -To set `CACHE_NUGET_PACKAGES` to `false`, perform one of the following:
  -
  -* Locate your app manifest, `manifest.yml`, and set the `CACHE_NUGET_PACKAGES` environment variable to `false`:
  +* You have added pre-release packages to test a new feature, then decided to revert back to the main NuGet feed. You may need to remove the packages you changed from the cache to avoid conflicts.
  +
  +Disabling NuGet caching both clears any existing NuGet dependencies from the staging cache and prevents the buildpack from adding NuGet dependencies to the staging cache. To disable NuGet package caching, set the `CACHE_NUGET_PACKAGES` environment variable to `false`. If the variable is not set, or set to a different value, there is no change.
  +
  +Perform one of the following procedures to set `CACHE_NUGET_PACKAGES` to `false`:
  +
  +* Locate your app manifest, `manifest.yml`, and set the `CACHE_NUGET_PACKAGES` environment variable, following the format of the example below:
   
       ```yml
       ---
  
positive.code: 
      <pre class="terminal">$ cf set-env YOUR-APP CACHE_NUGET_PACKAGES false</pre>
  
  For more information, see the [Environment Variables](../../devguide/deploy-apps/manifest.html#env-block) section
  of the <em>Deploying with Application Manifests</em> topic.
  
  ## <a id='framework-dependent'></a>Framework-Dependent Deployments##
  
  This is the recommended workflow if you deploy an app in an offline setting.
  
  In a framework-dependent deployment (FDD), you deploy only your app and third-party dependencies.
  For information about deploying FDDs, see
  [Framework-dependent deployments (FDD)](https://docs.microsoft.com/en-us/dotnet/core/deploying/index#framework-dependent-deployments-fdd)
  in the Microsoft documentation.
  To deploy an FDD using the buildpack, do the following:
  
  1. Publish the app by running the `dotnet publish [-f YOUR-FRAMEWORK] [-c Release]` command.
  
  1. Navigate to the `bin/Debug|Release/YOUR-FRAMEWORK/YOUR-RUNTIME>/publish` directory.
  Alternatively, if your app uses a `manifest.yml`, specify a path to the output folder of `dotnet publish`.
  This allows you to push your app from any directory.
  
  1. Push your app.
  
  <p class="note"><strong>Note:</strong> Set <code>applyPatches: false</code> in  <code>*.runtimeconfig.json</code> only if you want
  to pin your .NET Framework to a specific version. This prevents your app
  from receiving updates to the runtime version and assemblies.</p>
  
  ## <a id='self-contained'></a>Self-Contained Deployments##
  
  In a self-contained deployment (SCD), you deploy your app, third-party dependencies,
  and the version of .NET Core that you used to build your app. For information about SCDs,
  see [Self-contained deployments (SCD)](https://docs.microsoft.com/en-us/dotnet/core/deploying/#self-contained-deployments-scd)
  in the Microsoft documentation.
  
  <p class="note"><strong>Note:</strong> Cloud Foundry does not recommend using the SCD workflow.
  Because this workflow results in a pre-published binary,
  the buildpack is not able to keep all your dependencies in sync and up to date.</p>
  
  When using the SCD workflow for deploying your app,
  you must specify a runtime in the `dotnet publish` command. For example:
  
  ```
  dotnet publish -r ubuntu14.04-x64
  ```
  
  In addition, you must include the specified runtime in the `RuntimeIdentifiers` section of the project file.
  
  ## <a id='dotnet-sdk'></a> Specify .NET Core SDKs
  
  To pin the .NET Core SDK to a specific version or version line, create a `buildpack.yml` file at the app root
  and add your SDK version in one of the following formats:
  
  ```
  dotnet-core:
    sdk: 2.1.201
  ```
  
  ```
  dotnet-core:
    sdk: 2.1.x
  
negative.code: </PropertyGroup>
  ```
  
  This is results in a fully vendored app but will require fewer buildpack updates.
  
  If you do not want to use this option you can set `buildpack.yml` to your desired .NET SDK line to keep the SDK up to date:
  
  ```
  
  ---
  dotnet-core:
  	sdk: 2.0.x
  ```
  
  **Note:** Dotnet releases `2.0.x` AspNetCore assemblies in the `2.1.200`-`2.1.299` SDK versions. `2.1.x` assemblies are released in the `2.1.300` and above SDK versions.
  
  ## <a id='port'></a>Configure the Listen Port ##
  
  For your .NET Core app to work on <%= vars.product_windows %>, you must modify the `Main` method to configure the app to listen on the port specified by the `$PORT` environment variable. <%= vars.product_windows %> sets this environment variable automatically.
  
  1. Open the file that contains your `Main` method.
  
  