World Backup ยท v1.0.0

Documentation shipped with this application release.

Back to What's New

IIS hosting and startup diagnostics

CoHo Appz World Backup / SmarterASP.NET / Visual Studio 2022

Updated October 5, 2026.

For HTTP 500.34 after republishing, use the current recovery guide and CoHo-Appz-World-Backup-IIS-Recovery-Patch.zip. The source now includes an explicit out-of-process web.config, and scripts/Publish.ps1 checks its actual output. For Visual Studio Folder publishing, run scripts/Test-IisPublish.ps1 against that output before uploading.

Keep the working hosting model when publishing

The web project (src/Mcs.Web/Mcs.Web.csproj) contains this project property:

<AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>

It makes future SDK publishes generate an out-of-process IIS configuration. It applies to both Visual Studio publishing and scripts/Publish.ps1. Keep any local target-framework changes and the matching host runtime; this fix does not require retargeting the solution.

A publish profile can override project properties. Search your web project's Properties/PublishProfiles/*.pubxml files for AspNetCoreHostingModel. Any existing override for this deployment should also be OutOfProcess. Keep credentials private and preserve your current publisher contact settings when publishing again. The production startup check still requires a real support email or HTTPS contact page.

If all your ASP.NET Core sites share one application pool, they must use compatible hosting modes. An out-of-process setting here does not change another site's configuration. In-process applications require their own application pools; a dedicated pool per application is another option when the hosting plan provides it.

Verify the published web.config

The configuration below is the normal-operation example for a framework-dependent publish of Mcs.Web. Logging is disabled after troubleshooting:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="*" verb="*"
             modules="AspNetCoreModuleV2"
             resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath="dotnet"
                  arguments=".\Mcs.Web.dll"
                  hostingModel="outofprocess"
                  stdoutLogEnabled="false"
                  stdoutLogFile=".\logs\stdout" />
    </system.webServer>
  </location>
</configuration>

hostingModel, stdoutLogEnabled, and stdoutLogFile belong on <aspNetCore>. Do not add them to the <add> element inside <handlers>.

Use the SDK-generated process path and arguments for your actual publish. A self-contained deployment may use an executable instead of dotnet and a DLL; do not replace that startup command with the example above. The supplied source now includes src/Mcs.Web/web.config with explicit out-of-process hosting. Leave SDK transformation enabled so the startup command matches the actual publish. The recovery patch merges an existing customized file rather than replacing it.

Earlier IIS patch (superseded by the recovery patch)

  1. Close Visual Studio and extract CoHo-Appz-World-Backup-IIS-Patch.zip to a separate folder.
  2. Run Apply-Patch.cmd and paste the full path to the solution folder. That folder must contain src/Mcs.Web/Mcs.Web.csproj.
  3. The script backs up files it changes to a timestamped CoHo-Appz-World-Backup-IIS-Backups folder beside the solution folder. It changes the hosting property in the web project, updates existing hosting overrides in .pubxml profiles, and corrects an existing source web.config if one is present. It also copies this guide into docs/IIS-HOSTING.md.
  4. Reopen the solution, build Release, and publish Mcs.Web to a local folder first. Inspect that folder's generated web.config using the checks above.
  5. Publish/upload that verified output with your usual Visual Studio profile. Preserve the site's configured publisher contact details and the generated companion download in App_Data/Downloads.
  6. Check the home page and /health after deployment. A deployment or pool restart ends existing in-memory pairing sessions; pair again as needed.

Backups of publish profiles may contain credentials. Keep the backup folder private and out of source control. To undo the patch, close Visual Studio and copy changed files back from the timestamped backup using the same relative paths. If the guide was newly created and has no backup, remove only that newly created guide. Run the patch again only if needed; an already applied patch makes no further changes.

The patch changes source files on your PC. It does not change the currently running site or restart an application pool. The checked source package does not include a compiled web application or Windows installer.

Temporary startup logging

If the deployed application fails to start:

  1. In File Manager, create logs alongside the deployed web.config, for example /WorldBackup/logs. Ensure the hosting application has write access.
  2. On the existing <aspNetCore> element, set stdoutLogEnabled="true" and stdoutLogFile=".\logs\stdout". Keep hostingModel="outofprocess" and your actual process path/arguments.
  3. Restart the assigned application pool, request the site once, then refresh File Manager. Open the newest stdout_*.log and read the first exception.
  4. Correct the reported error. Once the site works, set stdoutLogEnabled="false" and remove diagnostic logs you no longer need. These logs do not rotate automatically.

An absent stdout log does not prove that the application is healthy. A stopped pool can prevent the process from starting and the log from being created.

HTTP 503 recovery

Confirm the website is On in SmarterASP.NET's WEBSITES > Manage Websites > Site On/Off. Identify its assigned pool under the website's Application Pool setting. Go to Advanced Tools > Pool Manager, find that pool, and use Actions > Restart (or Start if stopped).

If the pool stops again, or 503 continues without a log, ask SmarterASP.NET support for the exact IIS status/substatus and the application pool's shutdown/failure events. Do not infer the root cause from the browser's generic 503 page. This project property prevents a publishing regression; it does not establish why the earlier pool became unavailable.

Validation limits

The patch/source archives were checked for ZIP integrity, XML validity, file inventory, and preservation of unrelated project files. The creation environment has no .NET SDK or PowerShell, so the apply script, C# build, and publish were not executed here. Your reported working deployment confirms the live site is running; it is not a test of this new source patch. Build and inspect a local publish before uploading.

References