HTTP 500.34 recovery and publishing correction

Date: October 5, 2026.

HTTP 500.34 means the IIS worker process is being asked to run both in-process and out-of-process ASP.NET Core applications. It is an IIS hosting conflict, before the page's logo or Blazor components run. Microsoft's supported resolution is separate application pools. For a shared pool, all participating ASP.NET Core apps must have compatible hosting settings; this application is configured for outofprocess.

The last supplied source still contains AspNetCoreHostingModel=OutOfProcess. Its logo patch does not change the web project, publish profiles, or IIS configuration. However, it left existing publish-profile and source/configuration overrides untouched. The actual deployed file and pool assignments have not been provided, so a particular override has not been confirmed as the cause.

Get the hosted site working

1. In SmarterASP.NET File Manager, back up the existing /WorldBackup/web.config privately, then edit that file.
2. On its aspNetCore element, set hostingModel="outofprocess". Keep the existing processPath, arguments, environment variables, and unrelated settings. Normal-operation logging can remain stdoutLogEnabled="false".
3. Ensure hostingModel, stdoutLogEnabled, and stdoutLogFile are not attributes of handlers/add. Remove those misplaced attributes from the handler if present.
4. Save the file, then restart the website's assigned application pool using SmarterASP.NET's Advanced Tools > Pool Manager > Restart. This can interrupt other sites in the same pool. Ensure the website is On and reload it.
5. If this file already says outofprocess, or the error persists, check the other ASP.NET Core applications assigned to that pool. An in-process application elsewhere in the same worker is incompatible. Ask SmarterASP.NET to identify the conflicting applications and assign this application its own pool, if available. Recycling alone cannot fix a remaining configuration conflict.

For the framework-dependent deployment shown earlier, the relevant elements should be:

<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" />

Do not replace a self-contained EXE startup command with the DLL example. Editing only the hosting-related attributes preserves your deployment's actual startup command. No recompilation or companion update is needed merely to correct the deployed IIS hosting model. A pool restart discards the server's in-memory pairing sessions, so pair again if necessary.

Apply the source recovery patch

1. Close Visual Studio and extract CoHo-Appz-World-Backup-IIS-Recovery-Patch.zip to a separate folder.
2. Run Apply-Patch.cmd and enter the existing solution folder containing src/Mcs.Web/Mcs.Web.csproj.
3. The patch backs up changed files beside the solution, then corrects the web-project hosting property, existing .pubxml overrides, and any source web.config. It creates the supplied source configuration only if none exists. Known root-level web transforms with an explicit hostingModel attribute are also corrected.
4. It adds the local verification/repair utilities and merges the hosting argument and output check into the supplied scripts/Publish.ps1. A customized publish script that cannot be safely matched stops the source patch before any writes; merge the small changes manually using SOURCE-CHANGES.patch.
5. Reopen Visual Studio and publish Mcs.Web to a local Folder first. This hosting patch does not require rebuilding the companion.

You can run .\scripts\Test-IisTools.ps1 on Windows to verify repair, setting preservation, idempotence, and rejection of invalid configurations before publishing. These PowerShell tests have been included but were not executed in the creation environment.

1. Run the output check before uploading:

.\scripts\Test-IisPublish.ps1 -PublishDirectory 'C:\YOUR_ACTUAL_WEB_PUBLISH_FOLDER'

Replace the token with your actual folder containing Mcs.Web.dll and web.config. If the check fails, inspect the reported configuration and the profile/transform that produced it. If it passes, upload the checked web output, preserving real publisher contact values and the existing companion download ZIP in App_Data/Downloads.

The check is built into scripts/Publish.ps1. Visual Studio publishing does not invoke that PowerShell check automatically; run it against the Folder output before uploading. This package does not change your target framework, installed runtime, contact configuration, publish credentials, logo, or backup/restore behavior.

Repair an existing local published configuration

Download the currently deployed web.config to a private local folder, or use the file in your existing local web publish folder. From the recovery patch folder, run Repair-WebConfig.cmd and enter that file's full local path. The utility changes only the hosting model, normal stdout logging, and misplaced handler attributes. It preserves startup commands, environment variables, rewrite rules, and other configuration.

Alternatively, from the solution folder:

.\scripts\Repair-IisWebConfig.ps1 -ConfigPath 'C:\YOUR_ACTUAL_WEB_PUBLISH_FOLDER\web.config'

It backs up the original outside the selected configuration folder. Upload only the repaired file to the same application root, then restart the assigned pool. Do not upload the private backup folder. The supplied standalone web.config is a simple framework-dependent example; merging your existing file avoids discarding custom settings.

Changes, checks, and rollback

• Added explicit src/Mcs.Web/web.config with out-of-process hosting.
• Added XML utilities, a publish-output checker, and a local configuration repair utility under scripts.
• Publish.ps1 now passes -p:AspNetCoreHostingModel=OutOfProcess and checks the resulting web.config before companion packaging.
• The recovery patch merges existing source/profile configuration and records new files in ADDED-FILES.txt. Existing targets/frameworks and publisher/contact files are preserved.
• Source XML, preservation cases, and ZIP contents were checked. There is no .NET SDK, PowerShell, or Windows desktop in the creation environment, so actual PowerShell execution, publishing, and the live pool configuration were not tested here. Build and check the local output before deploying.

For rollback, restore changed source files from the timestamped CoHo-Appz-World-Backup-IIS-Recovery-Backups folder and remove newly created files listed in ADDED-FILES.txt. Restore a repaired published configuration from its separately printed IIS-WebConfig-Backups folder if needed. Keep backups private, especially when profiles or configuration contain credentials.

Official references

• Microsoft: HTTP 500.34 and hosting-model conflicts.
• Microsoft: Out-of-process IIS hosting.
• Microsoft: Source web.config and publishing.
• SmarterASP.NET: Recycle an application pool.