Choose a reproducible deployment package
Create the package through the project’s publish workflow. Record its identifier, target .NET version, processor architecture and deployment model. Copying selected files out of a development bin directory makes missing dependencies harder to diagnose in production.
Framework-dependent deployment uses a compatible runtime on the server. Self-contained deployment includes a runtime, but still needs the appropriate IIS integration. Retain the previous working package and environment configuration as separate recovery inputs.
Verify the IIS hosting layers
| Layer | Evidence to collect |
|---|---|
| Hosting Bundle | ASP.NET Core Module and hosting components appropriate for the app are installed. |
| Physical directory | The site points to the verified publish output. |
| Application pool | Architecture, identity and hosting model are compatible. |
| web.config | The generated process path and arguments match the actual package. |
Keep production settings under control
Inventory connection strings, external service credentials and environment variables without exposing them in public diagnostic pages. A staging site connected to production storage can modify real data even when its homepage appears harmless.
Give the application identity read access to its code and write access only to required log or upload directories. If startup fails with access denied, identify the exact resource instead of granting broad write access across customer sites.
Run an application acceptance test
- Open a page, a static asset and an API route on a test hostname. Check expected content as well as the HTTP status.
- Sign in, create a harmless test record and read it back. Verify session cookies and HTTPS behavior.
- Restart the application pool in a controlled window and repeat the first request to test a cold start.
- Record the deployed build, test time and log results. Repeat critical checks from an external network after the DNS switch.
Diagnose startup before changing settings
For 500.30 or 502.5, correlate the IIS result with Windows events and the application startup error. A missing runtime, denied resource and invalid application setting require different remedies; the status alone does not identify the root cause.
Restrict any temporary diagnostic logs and disable verbose collection after investigation. If the deployment also changes the database schema, restoring old files may not restore compatibility. Include the data transition in the rollback procedure.
Frequently asked questions
Does installing AdaPanel make every .NET app compatible?
No. Validate the project target, dependencies and IIS hosting requirements. Site management through a control panel does not replace application acceptance tests.
Does self-contained hosting still need IIS integration?
Yes. Packaging the runtime and integrating with IIS are separate concerns. Check the ASP.NET Core Module requirements for the selected deployment model.
Is a working homepage enough?
No. Test authentication, database access, uploads and a cold start. Define a small acceptance list around the application’s critical operations.
Can rollback consist of copying the previous files?
Only if the old application remains compatible with the current configuration and data. Database changes need a separate compatibility and recovery decision.