anchor.diff:    sdk: 2.x
   ```
   
  -The buildpack chooses which SDK to install based on the files present at the app root, according to the following order of precedence:
  +The buildpack chooses which SDK to install based on the files present at the app root using the following order of precedence:
   
   1. `buildpack.yml`
   1. `global.json`
  -1. If the app contains only `*.fsproj` files, the buildpack installs the latest 1.1.x SDK.
  -
  -<p class="note"><strong>Note</strong>: The app respects the SDK version specified in <code>global.json</code> at runtime. If you provide versions in both <code>global.json</code> and <code>buildpack.yml</code> files, ensure that you specify the same versions in both files.</p>
  -
  -## <a id='dotnet-runtime'></a>Specifying .NET Runtime Versions
  -### <a id='dotnet-runtime-source-based'></a>For source-based apps
  -
  -Specify a minor version of the .NET Runtime.
  -Do not specify a patch version, because
  +1. `*.fsproj`
  +
  +<p class="note"><strong>Note</strong>: The app respects the SDK version specified in <code>global.json</code> at runtime.
  +If you provide versions in both <code>global.json</code> and <code>buildpack.yml</code> files,
  +ensure that you specify the same versions in both files.</p>
  +
  +## <a id='dotnet-runtime'></a>Specify .NET Runtime Versions
  +
  +### <a id='dotnet-runtime-source-based'></a>Source-Based Apps
  +
  +For source-based apps, specify a minor version of the .NET Runtime.
  +Do not specify a patch version because
   buildpacks contain only the two most recent patch versions of each minor version.
   
  -Add the following to your `.csproj` or `.fsproj` file to lock the .NET Runtime version:
  +To lock the .NET Runtime version, add the following to your `.csproj` or `.fsproj` file :
   
   ```
   <PropertyGroup>
  
positive.code:     $ 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 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 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
  
  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 = <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>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, 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
      ---
  
negative.code: </PropertyGroup>
  ```
  
  ### <a id='dotnet-runtime-fdd'></a>Framework-Dependent Apps
  
  In your `.runtimeconfig.json` app, the latest .NET Runtime patch version is used by default.
  To pin to a specific .NET Runtime version, add the `applyPatches` property and set it to `false`.
  
  ```
  {
  