The Azure Application Gateway supports various routing options. With path-based routing, one or the other backend can be called depending on the URL. Things get a little more complicated when the apps on the app services are distributed in virtual directories.

In the following scenario, 2 app services were created. The first app service contains only one application that can be called under /app1. The second app service contains /app2 and /app3 under the path /virtdir, that is connected to the physical path site\app3. Below is an image of the path mapping of the second app service:

Deploy to Virtual Path

There are a few things to consider when deploying apps to a virtual directory. It must be a Windows App Service plan and the easiest way to deploy the application is via FTP. To do this, the correct path on the app service must be specified under Site path and the server need to be connected via port 990.

In the .NET source code, all projects on the same App Service should have the hosting model set to OutOfProcess (is configured in the *.csproj-files). The default value is InProcess and results in error 500.35 ANCM Multiple In-Process Applications in same Process.

<PropertyGroup>
	<TargetFramework>net8.0</TargetFramework>
	<Nullable>enable</Nullable>
	<ImplicitUsings>enable</ImplicitUsings>
	<AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>
</PropertyGroup>

Configure the Application Gateway

With the Application Gateway, the individual targets must be divided into individual back-end pools. The routing of the shared public listener is then done using a path-based routing rule. The configuration of the rule looks like this:

All backend settings have their own health probe. If the app is deployed to the site\wwwroot, the path is not overridden. If the app is stored in a virtual path (here /app3 with http-settings-3), the backend path is overridden to the virtual path (/virtdir/app3).

If the configuration is correct, all calls work as expected: