User Documentation

C#/.NET Core

Sign up for Upsun

Get your free trial by clicking the link below.

Get your Upsun free trial supports deploying .NET applications by allowing developers to define a build process and pass its variables to the .NET Core build environment.

Supported versions Anchor to this heading

You can select the major and minor version.

Patch versions are applied periodically for bug fixes and the like. When you deploy your app, you always get the latest available patches.

Grid and Dedicated Gen 3 Dedicated Gen 2
  • 7.0
  • 6.0
None available

Specify the language Anchor to this heading

To use .Net Core, specify dotnet as your app’s type:
type: 'dotnet:<VERSION_NUMBER>'

For example:
type: 'dotnet:7.0'

Building the application Anchor to this heading

To build basic applications in .NET containers, it’s enough to use the dotnet publish command with the default framework-dependent deployment:
    build: |
        set -xe
        dotnet publish --output "$PLATFORM_OUTPUT_DIR" \
            -p:UseRazorBuildServer=false \

where PLATFORM_OUTPUT_DIR is the output directory for compiled languages available at build time.

Typically, .NET Core builds start a collection of build servers, which are helpful for repeated builds. On, however, if this process isn’t disabled, the build process doesn’t finish until the idle timeout is reached.

As a result, you should include -p toggles that disable the Razor compiler for dynamic CSHTML pages (UseRazorBuildServer) and the .NET MSBuild compiler (UseSharedCompilation).

If you want multiple builds for your application, make sure to call dotnet build-server shutdown at the end of your build hook.

Running the application Anchor to this heading

.NET Core applications should be started using the web.commands.start directive in This ensures that the command starts at the right moment and stops gracefully when a redeployment needs to be executed. Also, should the program terminate for any reason, it’s automatically restarted. Note that the start command must run in the foreground.

Incoming requests are passed to the application using either a TCP (default) or Unix socket. The application must use the appropriate environment variable to determine the URI to listen on. For a TCP socket (recommended), the application must listen on, using the PORT environment variable.

There is an Nginx server sitting in front of your application. Serving static content via Nginx is recommended, as this allows you to control headers (including cache headers) and also has marginal performance benefits.

Note that HTTPS is also terminated at the Nginx proxy, so the app.UseHttpsRedirection(); line in Startup.cs should be removed. To force HTTPS-only, refer to the routes documentation.

The following example configures an environment to serve the static content folders commonly found in ASP.NET MVC templates using Nginx, while routing other traffic to the .NET application.
            root: "wwwroot"
            allow: true
            passthru: true
                # Serve these common asset types with customs cache headers.
                    allow: true
                    expires: 300s
        start: "dotnet WebApplication1.dll"

You can also route all requests to the application unconditionally:
            allow: false
            passthru: true

        start: "dotnet WebApplication1.dll"

Project templates Anchor to this heading

The following list shows templates available for .NET Core apps.

A template is a starting point for building your project. It should help you get a project ready for production.

Templates in development.

Is this page helpful?