Deploy .NET Apps with Azure Pipelines

By Khimananda Oli | Last reviewed: August 2026

Shipping .NET applications reliably requires more than a simple build script; you need a repeatable, auditable process that handles dependencies, secrets, and environment-specific configurations without manual intervention. When you deploy .NET apps with Azure Pipelines, you gain native integration with the Microsoft ecosystem, but success depends on structuring your YAML correctly and avoiding common configuration pitfalls. This guide walks through the exact pipeline architecture, security patterns, and deployment steps I use in production environments to ensure consistent, safe releases.

How do you structure a YAML pipeline to deploy .NET apps with Azure Pipelines?

A well-structured pipeline separates concerns into distinct stages: Build, Test, and Deploy. This separation ensures that a failed test never triggers a production deployment and allows you to reuse build artifacts across environments. Before writing YAML, review the Azure DevOps YAML pipelines practical guide to understand schema fundamentals and validation techniques.

Define triggers and pool configuration

Your pipeline should trigger only on relevant branches to avoid wasting build minutes. Use path filters if your repository contains multiple projects. Always specify a VM image explicitly rather than relying on defaults, as Microsoft updates images regularly and implicit versions can break builds unexpectedly.

trigger:
  branches:
    include:
      - main
      - release/*
  paths:
    include:
      - src/
    exclude:
      - docs/

pool:
  vmImage: 'ubuntu-24.04'

variables:
  buildConfiguration: 'Release'
  dotnetVersion: '8.x'

Restore, build, and publish in sequence

The DotNetCoreCLI@2 task handles all .NET operations. A common mistake is combining restore and build into a single step; keep them separate so you can cache restored packages independently. Publishing creates a self-contained output folder that includes all dependencies, which is critical for consistent deployments.

- task: DotNetCoreCLI@2
  displayName: 'Restore NuGet packages'
  inputs:
    command: 'restore'
    projects: '/*.csproj'
    feedsToUse: 'select'
    vstsFeed: 'my-feed'

- task: DotNetCoreCLI@2
  displayName: 'Build solution'
  inputs:
    command: 'build'
    projects: '/*.csproj'
    arguments: '--configuration $(buildConfiguration) --no-restore'

- task: DotNetCoreCLI@2
  displayName: 'Publish application'
  inputs:
    command: 'publish'
    publishWebProjects: true
    arguments: '--configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory) --no-build'
    zipAfterPublish: true

How do you manage secrets securely when deploying .NET apps?

Never hardcode connection strings, API keys, or credentials in YAML files or application settings. Azure Pipelines integrates directly with Azure Key Vault through service connections, allowing you to fetch secrets at runtime without exposing them in logs or variable groups. For deeper guidance on secret handling patterns, see using Azure Key Vault secrets in pipelines.

Configure Key Vault integration

Add the AzureKeyVault@2 task early in your pipeline, typically right after checkout. This task downloads specified secrets and exposes them as pipeline variables. The service connection used must have GET permissions on the Key Vault's access policy or RBAC role.

- task: AzureKeyVault@2
  displayName: 'Fetch secrets from Key Vault'
  inputs:
    azureSubscription: 'Production-Service-Connection'
    KeyVaultName: 'prod-app-kv'
    SecretsFilter: 'DbConnectionString,ApiKey,RedisPassword'
    RunAsPreJob: false

Override app settings during deployment

When deploying to App Service, use the appSettings parameter in the deployment task to inject Key Vault-sourced values. This overrides whatever exists in the portal or web.config, ensuring the deployed instance uses exactly what the pipeline provides. Values are masked automatically in logs.

- task: AzureRmWebAppDeployment@4
  displayName: 'Deploy to Staging Slot'
  inputs:
    ConnectionType: 'AzureRM'
    azureSubscription: 'Production-Service-Connection'
    appType: 'webAppLinux'
    WebAppName: 'my-dotnet-app'
    deployToSlotOrASE: true
    SlotName: 'staging'
    packageForLinux: '$(Build.ArtifactStagingDirectory)//*.zip'
    appSettings: '-ConnectionStrings__Default "$(DbConnectionString)" -ApiKey "$(ApiKey)"'

What testing strategy prevents broken deployments in Azure Pipelines?

Testing in CI must be fast, deterministic, and gated. If tests fail, the pipeline stops immediately and no artifact is published. I recommend running unit tests first (under 5 minutes), then integration tests against ephemeral containers or managed test databases. Refer to integration testing in CI pipelines for patterns that work reliably with .NET and Azure SQL.

Run tests and publish results

Always use --no-build when running tests if you've already built the solution; this avoids recompilation and speeds up feedback. Publish test results in TRX format so Azure DevOps renders them in the UI with pass/fail breakdowns and stack traces.

- task: DotNetCoreCLI@2
  displayName: 'Run unit tests'
  inputs:
    command: 'test'
    projects: '/*Tests.csproj'
    arguments: '--configuration $(buildConfiguration) --no-build --collect:"XPlat Code Coverage" --logger trx'
    publishTestResults: true

- task: PublishTestResults@2
  displayName: 'Publish test results'
  condition: always()
  inputs:
    testResultsFormat: 'VSTest'
    testResultsFiles: '/*.trx'
    mergeTestResults: true
    failTaskOnFailedTests: true

Enforce code coverage thresholds

Add a quality gate that fails the pipeline if coverage drops below your team's baseline. This prevents gradual erosion of test quality over time. Combine this with dependency scanning to catch vulnerable packages before they reach production.

How does Azure App Service deployment compare to AKS for .NET workloads?

Choosing between App Service and Azure Kubernetes Service (AKS) depends on operational complexity tolerance, scaling requirements, and team expertise. App Service is fully managed with minimal overhead; AKS offers fine-grained control at the cost of significant operational burden. For teams new to containers or managing fewer than five services, App Service is usually the better starting point. If you're evaluating container orchestration, read Azure AKS practical guide for realistic operational expectations.

Use deployment slots for zero-downtime releases

App Service deployment slots allow you to deploy to a staging slot, validate it with smoke tests, then swap into production atomically. This eliminates downtime during deployments and provides an instant rollback mechanism by swapping back. Always enable "Swap with preview" for critical applications to verify warm-up behavior.

- task: AzureRmWebAppDeployment@4
  displayName: 'Swap staging to production'
  inputs:
    ConnectionType: 'AzureRM'
    azureSubscription: 'Production-Service-Connection'
    appType: 'webAppLinux'
    WebAppName: 'my-dotnet-app'
    SourceSlot: 'staging'
    SwapWithProduction: true
    PreserveVnet: true

How do you optimize pipeline performance and caching for .NET builds?

NuGet restore is often the slowest part of a .NET pipeline. Enable caching to skip redundant downloads across runs. Azure Pipelines provides a built-in Cache@2 task that hashes your packages.lock.json or *.csproj files to determine cache validity. Without caching, every build re-downloads identical packages, adding 2–5 minutes unnecessarily.

Enable NuGet caching correctly

Generate a lock file to ensure deterministic cache keys. Without it, the cache key may not invalidate properly when dependencies change, leading to stale package resolution. Add <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile> to your Directory.Build.props and commit the resulting packages.lock.json.

- task: Cache@2
  displayName: 'Cache NuGet packages'
  inputs:
    key: 'nuget | "$(Agent.OS)" | /packages.lock.json'
    restoreKeys: |
      nuget | "$(Agent.OS)"
    path: $(NUGET_PACKAGES)
    cacheHitVar: NUGET_CACHE_HIT

- task: DotNetCoreCLI@2
  displayName: 'Restore NuGet packages'
  condition: ne(variables.NUGET_CACHE_HIT, 'true')
  inputs:
    command: 'restore'
    projects: '/*.csproj'
    feedsToUse: 'select'
    vstsFeed: 'my-feed'

Parallelize independent jobs

If your solution contains multiple independent projects (e.g., API, background worker, frontend), run their build/test jobs in parallel using job dependencies. This reduces total pipeline duration significantly on larger solutions. Use dependsOn only where ordering is actually required.

Reliable .NET Deployment Requires Intentional Pipeline Design

When you deploy .NET apps with Azure Pipelines, reliability comes from deliberate choices: separating stages, securing secrets outside source control, enforcing test gates, choosing the right hosting target, and optimizing build performance through caching. These aren't optional best practices—they're the difference between a pipeline that breaks at 2 AM and one your team trusts completely. Start with the YAML structure outlined here, add Key Vault integration before your first production deploy, and measure your cache hit rate weekly. If your pipeline feels fragile or your deployments require manual verification steps, the foundation needs work before adding more automation. Need help auditing your existing pipeline or designing one from scratch? Reach out to discuss your deployment challenges.