anchor.diff:  }
   ```
   
  -## <a id='specify-version'></a>Specify a .NET Framework Version ##
  -
  -Lock the .NET Framework to a minor version. Do not lock to a patch version, because 
  -buildpacks contain only the two most recent patch versions of each minor version.
  -
  -To lock the .NET Framework version in a `.csproj` app:
  -
  -```
  -  <PropertyGroup>
  -    <TargetFramework>netcoreapp2.1</TargetFramework>
  -    <RuntimeFrameworkVersion>2.1.*</RuntimeFrameworkVersion>
  -  </PropertyGroup>
  -```
  -
  -In a `.runtimeconfig.json` app, the latest .NET Framework patch version is used by default. To pin to a specific .NET Framework version, include the `applyPatches` property and set it to `false`:
  -
  -```
  -{
  -  "runtimeOptions": {
  -    "tfm": "netcoreapp2.0",
  -    "framework": {
  -      "name": "Microsoft.NETCore.App",
  -      "version": "2.0.0"
  -    },
  -    "applyPatches": false
  -  }
  -}
  -```
  -
  -## <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. If the app uses `project.json`, set `project` to the directory containing the `project.json` file of the main project.
  -
  -2. If the app uses MSBuild, set `project` to the `*.csproj` or `*.fsproj` file of the main project.
  -
  -For example, if an app using MSBuild 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, `MyApp.Web`. The buildpack attempts to execute the main project with `dotnet run -p src/MyApp.Web/MyApp.Web.csproj`.
  -
  -## <a id='disconnected-environments'></a>Push an App in a Disconnected Environment ##
  -
  -For offline use, you can cache the binaries in `manifest.yml` with the buildpack.
  -
  -You can push apps with their other dependencies following these steps:
  -
  -1. Publish the app by running `dotnet publish -r ubuntu.14.04-x64`.
  -
  -    <p class="note"><strong>Note</strong>: For this publish command to work, modify your app code so the .NET CLI publishes it as a self-contained app. For more information, see <a href="https://docs.microsoft.com/en-us/dotnet/articles/core/deploying/">.NET Core Application Deployment</a>.
  -    </p>
  -
  -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.
  -
  -## <a id='disabling-nuget'></a>Disabling 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='custom-libraries'></a>Add Custom Libraries ##
   
   If your app requires external shared libraries that are not provided by the rootfs or the buildpack, you must place the libraries in an `ld_library_path` directory at the app root.
  
positive.code:   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.
  
  <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>
  
  
negative.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:
      - `*.csproj`:
  
          ```xml
  