ASP.NET Core Deployment - MSDN Documentation

Introduction to ASP.NET Core Deployment

Deploying an ASP.NET Core application involves making your application accessible to users over the network. This can range from deploying to a single server to a distributed cloud environment. ASP.NET Core offers flexibility in how and where you deploy your applications.

Key considerations for deployment include:

Target environment (e.g., Windows, Linux, macOS, Docker, Azure, AWS)
Hosting model (e.g., In-process, Out-of-process)
Deployment artifacts (e.g., self-contained, framework-dependent)
Configuration management
Logging and monitoring
CI/CD pipelines

Deployment Targets

ASP.NET Core can be deployed to a variety of platforms and services:

Self-Hosted Deployment

You can host ASP.NET Core applications directly on your own infrastructure, such as web servers running Windows or Linux.

Windows

On Windows, you can use IIS (Internet Information Services) with the ASP.NET Core Module, or host directly using Kestrel. Kestrel is a cross-platform, high-performance, event-driven network I/O library built for ASP.NET Core.

Note:

For IIS deployment, ensure you have the ASP.NET Core Module installed. This module handles integration between IIS and Kestrel.

Linux

On Linux, you typically run your application using Kestrel and often place it behind a reverse proxy like Nginx or Apache. This provides benefits like load balancing, SSL termination, and static file serving.

# Example Nginx configuration snippet
server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://localhost:5000; # Assumes Kestrel is running on port 5000
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection keep-alive;
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Containerization (Docker)

Docker provides a standardized way to package your application and its dependencies into a container. This ensures consistency across different environments.

Create a Dockerfile in your project's root:

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build AS publish
WORKDIR /app

COPY . .
RUN dotnet restore
RUN dotnet publish -c Release -o /app/publish

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS runtime
WORKDIR /app
COPY --from=publish /app/publish .
EXPOSE 80
ENTRYPOINT ["dotnet", "YourApp.dll"]

Cloud Platforms

Major cloud providers offer specialized services for hosting ASP.NET Core applications:

Azure App Service: A fully managed platform for building, deploying, and scaling web apps.
Azure Kubernetes Service (AKS): For container orchestration using Kubernetes.
AWS Elastic Beanstalk: A service for deploying and scaling web applications and services.
Amazon Elastic Container Service (ECS): For container orchestration.

Deployment Artifacts

When you publish your ASP.NET Core application, you create deployment artifacts. You can choose between two main deployment modes:

Framework-Dependent Deployment (FDD)

This is the default deployment mode. The published output does not include the .NET runtime. The user must have a compatible .NET runtime installed on the target machine.

dotnet publish -c Release

The published output will contain your application assemblies and dependencies, but not the .NET runtime itself.

Self-Contained Deployment (SCD)

This mode includes the .NET runtime with your application. Users do not need to install .NET separately on the target machine. This results in a larger deployment size.

dotnet publish -c Release --self-contained true -r

Replace <runtime-identifier> with the appropriate identifier, e.g., win-x64, linux-x64, or linux-musl-x64.

Tip:

Self-contained deployments are useful when you need to control the exact version of the .NET runtime or when deploying to environments where installing the runtime is not feasible.

Configuration Management

Managing application configuration is crucial for deployment. ASP.NET Core's configuration system allows you to load settings from various sources, such as JSON files, environment variables, and command-line arguments.

For deployment, it's common practice to use environment-specific configuration files (e.g., appsettings.Production.json) and environment variables.

// Program.cs (example)
var builder = WebApplication.CreateBuilder(args);

// Load appsettings.json and appsettings.{Environment}.json
builder.Configuration.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true);
builder.Configuration.AddJsonFile($"appsettings.{builder.Environment.EnvironmentName}.json", optional: true, reloadOnChange: true);

// Add environment variables and command-line arguments
builder.Configuration.AddEnvironmentVariables();
builder.Configuration.AddCommandLine(args);

var app = builder.Build();

// ... rest of your application setup

Warning:

Never commit sensitive information like connection strings or API keys directly into your source code. Use secure methods like Azure Key Vault, AWS Secrets Manager, or environment variables.

Next Steps

This section provides a foundational understanding of ASP.NET Core deployment. For deeper dives into specific scenarios, consult the official documentation for your chosen hosting platform.

Deploying to IIS Deploying to Linux Deploying with Docker Deploying to Azure