Source-Based, Non-Published Deployments

When using this workflow, you push the source code for your app to Cloud Foundry by running the cf push command.
Note that for a source-based, non-published deployment, you push the source code for your app, not the output directory of the dotnet publish 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 source-based, non-published deployments, see the following sections:

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.

To specify your main project, create a .deployment file in the root folder of the app
that sets the path to the main project in the following format:

[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 your 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:

[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 using the dotnet run -p src/MyApp.Web/MyApp.Web.csproj command.

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
in the Microsoft documentation.

Disable and Clear Your 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, do one of the following:

Locate your app manifest, manifest.yml, and set the CACHE_NUGET_PACKAGES environment variable to false:

Use cf set-env to set the CACHE_NUGET_PACKAGES environment variable on the command line:

cf set-env APP-NAME CACHE_NUGET_PACKAGES false

Where APP-NAME is the name of your app.

For more information, see the Environment Variables section
of the Deploying with Application Manifests topic.

Framework-Dependent Deployments

For a framework-dependent deployment (FDD), you deploy only your app and third-party dependencies.
Cloud Foundry recommends using this workflow if you deploy an app in an offline setting.
For information about deploying FDDs, see
Framework-dependent deployments (FDD)
in the Microsoft documentation.

To deploy an FDD using the buildpack, do the following:

Publish the app by running the dotnet publish command:

dotnet publish [-f YOUR-FRAMEWORK] [-c Release]

Where YOUR-FRAMEWORK is your target framework.

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.

Push your app.

Note: Set applyPatches: false in *.runtimeconfig.json 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.

Self-Contained Deployments

For 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)
in the Microsoft documentation.

Note: 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.

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.

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

dotnet-core:
sdk: 2.x

The buildpack chooses what SDK to install based on the files present at the app root in the following order of precedence:

buildpack.yml

global.json

*.fsproj

Note: The app respects the SDK version specified in global.json at runtime.
If you provide versions in the global.json and buildpack.yml files,
ensure that you specify the same versions in both files.

Specify .NET Runtime Versions

This section explains how to specify a .NET Runtime version for source-based and framework-dependent apps.

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.

If you want to lock the .NET Runtime version, add the following to your .csproj or .fsproj file:

Framework-Dependent Apps

In your .runtimeconfig.json app, the latest .NET Runtime patch version is used by default.
If you want to set a specific .NET Runtime version, add the applyPatches property and set it to false as follows:

Push an App in a Disconnected Environment

For offline environments, Cloud Foundry recommends using the Framework-Dependent Deployments
workflow. This workflow enables the deployed app to use the latest runtime provided by the offline buildpack.

Maintain ASP.NET Core Assemblies

Note: This section applies only to source-based and framework-dependent deployments.

This results in a fully vendored app that requires fewer buildpack updates.

Alternatively, to keep your SDK up to date, you can set buildpack.yml to the .NET SDK line you want to use:

---
dotnet-core:
sdk: 2.0.x

Note:2.0.x ASP.NET Core assemblies are released
in the 2.1.200-2.1.299 SDK versions,
and 2.1.x assemblies are released in the 2.1.300 and above SDK versions.

Configure the Listen Port

For your .NET Core app to work on PASW,
you must modify the Main method to configure the app to listen on the port specified by the $PORT environment variable.
PASW sets this environment variable automatically.

Open the file that contains your Main method.

Add a using statement to the top of the file.

usingMicrosoft.Extensions.Configuration;

Add the following lines before the line var host = new WebHostBuilder():

varconfig=newConfigurationBuilder().AddCommandLine(args).Build();

Add the following line after .UseKestrel():

.UseConfiguration(config)

This allows the buildpack to pass the correct port from $PORT to the app when running the initial startup command.

Add Microsoft.Extensions.Configuration.CommandLine as a dependency in *.csproj: