anchor.diff:  }
   ```
   
  -## <a id='offline'></a> Push an App in a Disconnected Environment
  -
  -For offline environments, Cloud Foundry recommends using the [Framework-Dependent Deployments](#framework-dependent)
  -workflow. This workflow enables the deployed app to use the latest runtime provided by the offline buildpack.
  -
  -## <a id='runtime-store'></a>Maintain Runtime Package Store
  -
  -<p class="note"><strong>Note:</strong> This section applies only to source-based and framework-dependent deployments.</p>
  -
  -For maintaining ASP.NET Core assemblies, update your `.csproj` file with the following:
  +
  +## <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. It is possible to use the [Self-Contained Deployment (SCD) workflow](#self-contained) in an offline setting, but it is not recommended.
  +
  +## <a id='runtime-store'></a>Runtime Package Store
  +*This section applies only to source-based and framework-dependent deployment workflows*
  +
  +
  +The recommended workflow for maintaining AspNetCore assemblies is to update your `.csproj` file with:
   
   ```
   <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 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='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:
  
  ```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:
  
  ```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:
  
  * 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`:
  
      ```yml
      ---
  
negative.code: 
      <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**: Unless you want to pin your .NET Framework to a specific version (see below), do not set `applyPatches: false` in  `*.runtimeconfig.json`, as this will prevent your app from receiving updates to the runtime version and assemblies.
  
  
  ## <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
  ```
  
  The specified runtime should also be included in the `RuntimeIdentifiers` section of the project file.
  
  See [more details for FDD vs SCD deployments](https://docs.microsoft.com/en-us/dotnet/core/deploying/)
  
  
  ## <a id='dotnet-sdk'></a> Specifying .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:
  
  ```
  dotnet-core:
    sdk: 2.1.201
  ```
  
  The following formats are also valid:
  
  ```
  dotnet-core:
    sdk: 2.1.x
  