anchor.diff:    sdk: 2.x
   ```
   
  -```
  -dotnet-core:
  -  sdk: 2.x.x
  -```
  -
   The buildpack chooses which SDK to install based on the files present at the app root, according to the following order of precedence:
   
   1. `buildpack.yml`
  -2. `global.json`
  -3. If the app contains only `*.fsproj` files, the buildpack installs the latest 1.1.x SDK.
  +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>, ensure that you specify the same versions in both files.</p>
   
  
positive.code: 
      This allows the buildpack to pass the correct port from `$PORT` to the app when running the initial startup command.
  
  
  
  
  1. Add `Microsoft.Extensions.Configuration.CommandLine` as a dependency using one of the following:
      - `project.json`:
  
  		```json
          "Microsoft.Extensions.Configuration.CommandLine": "VERSION",
          ```
      - `*.csproj`:
  
          ```xml
  
negative.code: $ cf push MY-APP -b https://github.com/cloudfoundry/dotnet-core-buildpack.git
  </pre>
  
  ## <a id='source-based'></a>Source-based, Non-published Workflow ##
  
  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
      ---
      applications:
      - name: sample-aspnetcore-app
        memory: 512M
        env:
          CACHE_NUGET_PACKAGES: false
      ```
  
  * Use `cf set-env` to set the `CACHE_NUGET_PACKAGES` environment variable on the command line:
  
      <pre class="terminal">$ cf set-env YOUR-APP CACHE_NUGET_PACKAGES false</pre>
  
  See the [Environment Variables](../../devguide/deploy-apps/manifest.html#env-block) section of the <em>Deploying with Application Manifests</em> topic for more information.
  
  ## <a id='framework-dependent'></a>Framework Dependent Deployments (FDD) Workflow ##
  This is the recommended workflow when deploying an app in an offline setting.
  
  To deploy an [FDD](https://docs.microsoft.com/en-us/dotnet/core/deploying/index#framework-dependent-deployments-fdd) using the buildpack:
  
  
  1. Publish the app by running `dotnet publish [-f <framework>] [-c Release]`.
  
  1. Navigate to the `bin/<Debug|Release>/<framework>/<runtime>/publish` directory. Or, if your app uses a `manifest.yml`, specify a path to the publish output folder. This allows you to push your app from any directory.
  
  1. Push your app.
  
  **Note**: Do not set `applyPatches: false` in  `*.runtimeconfig.json`. This will prevent your app from receiving updates to the runtime version.
  
  ## <a id='self-contained'></a>Self-Contained Deployments (SCD) Workflow ##
  This workflow is not recommended. Because this workflow results in a prepublished binary, we are unable to keep all your dependencies in-sync and up-to-date.
  
  The SCD workflow is the same as the FDD workflow, except you must specify a runtime in the publish command:
  
  ```
  dotnet publish -r ubuntu14.04-x64
  ```
  
  See [more details for FDD vs SCD deployments](https://docs.microsoft.com/en-us/dotnet/core/deploying/)
  
  ## <a id='offline'></a>Offline Workflow - Push an App in a Disconnected Environment##
  
  Using the [Framework Dependent Deployment (FDD) workflow](#framework-dependent) is the recommended deployment method for an offline environment, as it will allow the deployed application to use the latest runtime provided by the offline buildpack. 
  
  ## <a id='dotnet-sdk'></a> .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 the following:
  
  ```
  