Publish with confidence
Build a release artifact and plan for configuration, migrations, persistent storage, and operational checks.
Here's what you'll be able to do.
- Create a release publish output
- Separate deployment settings from launch profiles
- Identify the checks needed before a public launch
Complete configuration, errors, and testing. Use a disposable local environment to rehearse the commands. This lesson prepares deployment; it does not provision or publish a public server.
Understand the idea
Publishing is the step that turns a project into an artifact a host can run. Deployment is the larger process that supplies configuration, applies schema changes, arranges persistent storage, starts the application, and checks that it behaves correctly.
A successful build is necessary but not sufficient. The application may still point at the wrong database, lose files when a container restarts, or fail to send account-confirmation emails. A reliable release makes those dependencies explicit.
Choose your environment
Open TaskBoard.csproj from the example download. Install the ASP.NET and web development workload and a Visual Studio release supporting .NET 10. Select the TaskBoard launch profile and press F5. Use Solution Explorer to find the files named below.
Install the .NET 10 SDK and C# Dev Kit. Open the TaskBoard folder in VS Code. Run dotnet restore, then dotnet run in the integrated terminal. Browse http://localhost:5300. Open files with Ctrl+P (Cmd+P on macOS).
Build and test the release artifact
Run the tests before publishing. dotnet publish creates the application files for deployment. A framework-dependent publish expects a compatible .NET runtime on the host; a self-contained publish includes a runtime for a chosen platform.
Use the same artifact through your release stages rather than rebuilding independently on each server. Record the version and keep a known-good artifact so rollback has a concrete target.
dotnet test TaskBoard.Tests/TaskBoard.Tests.csproj -c Release
dotnet publish TaskBoard/TaskBoard.csproj -c Release -o artifacts/taskboardRun from the directory containing both downloaded projects. The output directory is a build artifact, not a backup of your database.
Supply production configuration
The local launch profile is not the server configuration. Set ASPNETCORE_ENVIRONMENT explicitly and provide the intended connection string through your host’s configuration mechanism. For SQLite, choose a writable persistent path. A relative file inside a replaced deployment folder is fragile.
Configure HTTPS at the appropriate hosting layer, and configure forwarded headers only for trusted proxies when a reverse proxy terminates TLS. Do not trust arbitrary forwarded client headers from the public internet.
$env:ASPNETCORE_ENVIRONMENT = "Production"
$env:ConnectionStrings__Board = "Data Source=C:/AppData/TaskBoard/taskboard.db"
# Create and secure the persistent directory before starting the app.
# Apply migrations to this configured database as a separate release step.
dotnet artifacts/taskboard/TaskBoard.dll --urls http://localhost:5300Migrate and preserve the data
The sample deliberately does not auto-migrate on production startup. Review the generated migration, back up the database, and apply it as part of a controlled release. Rehearse both the upgrade and recovery plan using representative data.
SQLite works well for this local application, but a multi-instance deployment needs a deliberate storage architecture. Do not put independent copies of taskboard.db inside separate containers and expect a shared task list. Plan database hosting, file permissions, backup consistency, and data-protection key persistence together.
cd TaskBoard
dotnet tool restore
dotnet ef migrations list
# With the reviewed release and target connection configured:
dotnet ef database updateRun the update only after reviewing the migration and verifying the target connection. The development database and production database must not be confused.
Verify the running service
The /health endpoint confirms the process can respond. It does not query the database, verify email delivery, or prove a user can save a task. Add readiness checks appropriate to your hosting platform and keep detailed failures out of public responses.
Before a public launch, exercise registration, confirmed sign-in, task CRUD, account isolation, sign-out, error handling, backup recovery, and restart persistence. Configure a real email sender and confirmed-account policy. Monitor error rate and latency after rollout, and have a clear rollback decision.
Build and tests pass
Database migration reviewed and applied
Persistent storage and backups verified
HTTPS, proxy settings, and secrets configured
Email confirmation and recovery tested
Authentication and ownership checks pass
Health and readiness monitored
Rollback artifact and data recovery plan availableMake it your own.
Publish the app locally and compare the output with the source tree. Identify which settings must be supplied by the host and which data must survive replacing the publish directory.
See the solution & reasoning
The host supplies environment, connection settings, transport/proxy configuration, secrets, and persistent data-protection storage. The SQLite database must survive code replacement and process restarts. A publish folder contains application artifacts, not the durable state of the service.
When something doesn't work
A production startup with “no such table” often means the release migration was skipped or targeted a different database.
A restart that logs everyone out can indicate changing data-protection keys. Persist and share keys according to the host topology.
Repeated HTTPS redirects behind a proxy often mean the application does not correctly know the original request scheme. Configure trusted forwarded headers for that environment.
What does the sample /health endpoint prove?
That's another skill in your toolkit.
Your progress is saved in this browser. Sign in to save completion to your account.