Record the target framework from the project, its database engine, architecture, background-worker requirements and any native dependencies. Compare these with the runtime options on your hosting service. For ASP.NET Core, ask support whether your intended framework-dependent or self-contained deployment is supported. Self-contained deployment still needs suitable server integration and permissions.

1. Create a release build using your development tools and run its tests locally. Publish the application to an output directory; uploading the source project alone usually does not produce a working deployment.
2. Create a backup of the existing website and database. Arrange a maintenance window if the new release changes the database schema or could interrupt active sessions.
3. Open the domain in Plesk and review its hosting and application settings. For ASP.NET Framework, use the permitted ASP.NET settings that match the application. For Core, follow the supported deployment method supplied for that service.
4. Upload the published output to the correct document root. Keep the application's production configuration and secrets separate from development credentials. Do not deploy debugging tools or local database passwords.
5. Apply database migrations once, using the access method agreed for your account. Repeatedly opening an installer or migration endpoint can damage production data.
6. Restart or recycle the application through the available control, then test the health endpoint, login and a representative read-and-write operation.

Confirm that static files load, routes work after a browser refresh, outgoing messages arrive and uploads use an authorised writable location. Test HTTPS and the application's production error handling. Detailed exceptions should go to restricted logs rather than visitors.

Use this example only for a compatible SDK-style ASP.NET Core project when support has confirmed framework-dependent hosting and the required runtime. It is not the deployment procedure for an older ASP.NET Framework project.

On your development computer, open the project directory and replace YourApp.csproj with the actual project filename. Choose a new dedicated output directory outside the project and outside any live website.

dotnet publish ./YourApp.csproj --configuration Release --no-self-contained -p:UseAppHost=false --output ../publish-release

The UseAppHost=false option produces framework-dependent DLL output instead of a launcher tied to the development computers platform. This creates the files to deploy; it does not upload them, configure IIS or apply database migrations. Check that publishing succeeds, inspect the output for development secrets, and deploy that output through the approved Plesk workflow. Framework-dependent output requires the matching supported runtime and server hosting integration. If your application needs a specific Windows architecture or native dependency, use its reviewed publish profile rather than assuming these generic options are sufficient.

Capture the status code and relevant application log before changing settings. A missing runtime, incorrect process architecture or database permission can look like a general server error. Restore the previous application files if appropriate, but check whether database migrations require a separate rollback. Send support the target framework and published deployment type, not your entire secrets-bearing configuration.

• Getting your first website online with Windows hosting and Plesk
• Connecting a Windows-hosted application to MySQL or an available SQL Server database
• Troubleshooting IIS and application errors on Windows hosting
• Creating a backup plan you can actually restore

• Windows hosting with Plesk
• Plesk Hosting
• Dotnet Lifecycle

• Microsoft .NET publish command
• Microsoft .NET application publishing overview