I’m deploying a Blazor WebAssembly Hosted app (Server + Client) to IIS using an Azure DevOps Classic Release pipeline. Token replacement succeeds and the deployed files look correct, but after deployment the app loads and API calls return 404/500. I’m trying to understand whether this is a config/token issue or a runtime BaseAddress issue.

What I changed

We recently moved from full URLs in config to a BaseUri + relative endpoint pattern.

Project files

I now have two config files per project:

Server

• MyApp.Server/appsettings.Deploy.json

• MyApp.Server/appsettings.json

Client

• MyApp.Client/wwwroot/appsettings.Deploy.json

• MyApp.Client/wwwroot/appsettings.json (or whichever file Blazor loads from wwwroot)

Release pipeline steps (Classic)

1. Extract build zip to Extracted/

2. Run Replace Tokens on both appsettings.Deploy.json files

3. Copy tokenized appsettings.Deploy.json → appsettings.json (server + client) via PowerShell

4. Re-zip and deploy to IIS

Replace Tokens reports success, and after extraction the config values appear replaced correctly.

Client config example

MyApp.Client/wwwroot/appsettings.json ends up like this after replacement:

{
  "AppBaseUri": "devmyapp.com/",
  "CreateAssessmentEndpoint": "api/assessment/assessment-create/{0}"
}

Expected behavior

Client should call:
https://devmyapp.com/api/assessment/assessment-create/{0}

Actual behavior

After deployment, API calls fail. I see:

• 404/500 responses (from the client)

• Server-side error:
  Internal server error: An invalid request URI was provided. Either the request URI must be an absolute URI or BaseAddress must be set.

Question

Given that token replacement succeeds and the final files contain the expected values, what’s the correct way to configure BaseUri + relative endpoints in a Blazor WASM Hosted app deployed to IIS?

Specifically:

• Should AppBaseUri include the scheme (https://) and/or a trailing slash?

• Where should HttpClient.BaseAddress be set (Client Program.cs, Server, or both)?

• Is there anything special about loading appsettings.json from wwwroot that could cause it to not be used at runtime even though it exists in the deployed output?