HTTP 502.5: publisher settings lost on Visual Studio publish

Reviewed October 5, 2026, against the uploaded MCS-Minecraft-Web.zip.

Finding

The application's source and published configurations disagree:

src/Mcs.Web/Program.cs calls publisher.RequireConfigured() before building or starting the host whenever the environment is not Development. With the blank Visual Studio settings, that method throws:

Publisher configuration: Set a real support email address or HTTPS contact-page URL before publishing.

That is a definite startup blocker with those settings in Production, unless a later configuration source supplies a valid contact. It explains why editing the hosted settings or using the configured script output can work, then a separate Visual Studio publish can overwrite the settings and fail again. IIS's 502.5 page does not identify the exception itself; the current server's stdout or event log is still needed to conclusively attribute that live failure.

The uploaded source and Web Deploy staging web.config already use out-of-process hosting with processPath="dotnet" and arguments=".\Mcs.Web.dll". They do not specify an environment override. The published runtime configuration targets .NET 8, with Microsoft.NETCore.App and Microsoft.AspNetCore.App 8.0. No custom listening-port override was found in Program.cs.

What the patch changes

The supplied startup patch sets SupportEmail to admin@cohoappz.com, the public contact already configured in your artifacts/web/appsettings.json, in:

• src/Mcs.Web/appsettings.json, under Publisher.
• src/Mcs.Companion/publisher.json, at the root.

No new contact address has been invented. No publisher-configuration validation is removed. The website keeps its nested Publisher section; the companion keeps its flat Name/SupportEmail/ContactUrl structure. Existing local contacts are preserved by the apply script if either contact is already configured. An invalid existing contact is reported instead of overwritten.

The patch does not change web.config, project frameworks, application-pool assignments, runtime architecture, publish profiles, credentials, C# startup code, the logo, reconnect behavior, or backup/restore code. It does not edit stale bin/obj/artifacts copies. Republish from the corrected source to regenerate those outputs.

Immediate hosted-site repair

1. Back up /WorldBackup/appsettings.json, then edit only its Publisher section so it reads:

"Publisher": {
  "Name": "CoHo Appz",
  "SupportEmail": "admin@cohoappz.com",
  "ContactUrl": ""
}

1. Keep other settings in the file. The patch also includes server/appsettings.json, based on your uploaded source, for a site without additional customized settings. Prefer editing only the Publisher section when the live file has other changes.
2. Restart the new pool assigned to this application, request the home page, and check /health.

No assembly rebuild is required just to change the deployed JSON. Editing only the hosted copy is temporary: a later Visual Studio publish will copy the source settings again, so also apply the source patch below.

Apply and republish

1. Close Visual Studio. Extract MCS-Minecraft-Web-Startup-Patch.zip separately and run Apply-Patch.cmd.
2. Enter your solution folder, containing src/Mcs.Web/Mcs.Web.csproj. The script stages all configuration changes before writing and creates timestamped backups beside the solution.
3. Reopen Visual Studio and publish Mcs.Web from this corrected project. Your existing IISProfile can remain; it is not replaced by this patch. A local Folder publish lets you inspect the actual output before uploading.
4. Check the generated output's appsettings.json: Publisher.SupportEmail must be admin@cohoappz.com (or your actual alternative valid contact). Keep hostingModel="outofprocess" in the generated web.config and keep the site's actual companion ZIP in App_Data/Downloads.
5. For script publishing, use the existing workflow with the contact explicitly supplied:

.\scripts\Publish.ps1 -PublisherName 'CoHo Appz' -SupportEmail 'admin@cohoappz.com'

This produces the configured artifacts/web output; do not mix that output with blank settings from an older Visual Studio staging folder.

1. Restart the assigned pool after deployment and check the page and /health. A restart clears the in-memory pairing relay, so pair again as needed.
2. The companion's source contact is corrected too. Publish/package it on the next companion release so its Release connection validation has the same actual contact. Rebuilding the companion is not required to restore website startup.

The uploaded contact address is used as supplied; this review does not test mailbox delivery.

If HTTP 502.5 continues

Capture the exception instead of changing the hosting model or listening port again:

1. Create /WorldBackup/logs if absent. Ensure the new pool's identity has write access to it; changing pools can change the account that needs access.
2. On the existing aspNetCore element in the hosted web.config, temporarily set stdoutLogEnabled="true" and stdoutLogFile=".\logs\stdout". Keep the startup command and out-of-process hosting.
3. Restart that pool, request the site once, then open the newest stdout_*.log in File Manager. If no log is created, ask SmarterASP.NET for the ANCM event for the new pool and confirm its write access/runtime configuration.
4. If the log reports Publisher configuration, confirm the live appsettings.json and any appsettings.Production.json or Publisher__Name/Publisher__SupportEmail/Publisher__ContactUrl environment overrides. An empty override can still defeat a valid base JSON setting.
5. If it reports a missing framework, this framework-dependent publish needs both .NET 8 and ASP.NET Core 8 available to the new pool's dotnet process. Ask SmarterASP.NET to confirm the installed matching runtimes for that application. A .NET 10 runtime alone does not establish .NET 8 availability.
6. When the site works, set stdoutLogEnabled back to false. Share the first error and related stack trace, with any sensitive values removed, if further help is needed.

For an optional local test, open a terminal in the freshly published web folder on your development PC and run:

dotnet .\Mcs.Web.dll --environment Production --urls http://127.0.0.1:5189

Verify startup reaches a listening message; press Ctrl+C to stop it. This local HTTP address is only for diagnosis on your PC. Do not copy that URL or port into the IIS configuration. Local success does not prove that the hosting pool has the same runtime and permissions.

Verification and rollback

Completed here: source/publish-output comparison, JSON shape and contact checks, source patch contents, unchanged hosting/startup/backup files, and ZIP integrity. The creation environment has no .NET SDK, Windows runtime, or PowerShell, so the application and Windows apply script were not executed here. No server stdout log was included in the upload.

Restore the two changed JSON files from the timestamped MCS-Minecraft-Web-Startup-Backups folder to undo the patch. Remove newly added files listed in ADDED-FILES.txt if required. Restore the hosted JSON separately from its own backup if it was changed there. Avoid restoring the blank contact settings to Production, because the startup guard will reject them again.

Official references

• Microsoft: IIS 502.5 startup troubleshooting.
• Microsoft: Runtime environments and Production defaults.
• Microsoft: ANCM stdout logs.