IIISEnvironmentFeature could not be found on Ubuntu Linux

[radzawee]

I'm unable to run migrated web application on Ubuntu Linux with dotnet packages installed from Ubuntu repository (not from Microsoft).
App works fine with dotnet files downloaded manually using Microsoft script, but I prefer to use distro packages mechanism.

Exception:

System.TypeLoadException: Could not load type 'Microsoft.AspNetCore.Server.IIS.IIISEnvironmentFeature' from assembly 'Microsoft.AspNetCore.Server.IIS, Version=10.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.

Reproduction:

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddSystemWebAdapters();
var app = builder.Build();
app.UseSystemWebAdapters();
await app.RunAsync();

I'm building against .NET 10.

Packages details:

$ dotnet --list-runtimes
Microsoft.AspNetCore.App 8.0.25 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.4 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.25 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.4 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]

$ dpkg -l | grep ii | grep dotnet
ii  dotnet-apphost-pack-8.0               8.0.25-0ubuntu1~24.04.1                 amd64        Internal - targeting pack for Microsoft.NETCore.App 8.0
ii  dotnet-host-10.0                      10.0.4-0ubuntu1~24.04.1                 amd64        .NET host command line
ii  dotnet-hostfxr-10.0                   10.0.4-0ubuntu1~24.04.1                 amd64        .NET host resolver
ii  dotnet-hostfxr-8.0                    8.0.25-0ubuntu1~24.04.1                 amd64        .NET host resolver
ii  dotnet-runtime-10.0                   10.0.4-0ubuntu1~24.04.1                 amd64        .NET runtime
ii  dotnet-runtime-8.0                    8.0.25-0ubuntu1~24.04.1                 amd64        .NET runtime
ii  dotnet-runtime-deps-8.0               8.0.18-1                                amd64        dotnet-runtime-deps-debian 8.0.18
ii  dotnet-targeting-pack-8.0             8.0.25-0ubuntu1~24.04.1                 amd64        Internal - targeting pack for Microsoft.NETCore.App 8.0
ii  dotnet-templates-8.0                  8.0.125-0ubuntu1~24.04.1                amd64        .NET 8.0 templates

[twsouthwick]

it appears that the ubuntu version doesn't include the IIS component that we rely on. To fix this, we'd need to only selectively load this if it is available.

App works fine with dotnet files downloaded manually using Microsoft script, but I prefer to use distro packages mechanism.

Because of this, it's probably a low priority, but I'll see if CCA can do anything, otherwise, feel free to submit a PR!

[krylor]

Another data point, and I think it narrows the root cause: this is a distro-packaging difference,
not a type that .NET 10 removed.

The observation in this issue - that it works with Microsoft's installer but not with distro
packages - holds up. I
compared the same runtime version from both sources:

Microsoft.AspNetCore.Server.IIS.dll, 10.0.11 linux-x64	Size	IIISEnvironmentFeature
Microsoft build (Microsoft.AspNetCore.App.Runtime.linux-x64 10.0.11 on nuget.org)	668,968 bytes	present
Ubuntu 26.04 package (dotnet-runtime-10.0 10.0.11-0ubuntu1~26.04.1)	17,408 bytes	absent

$ strings -n 10 /usr/lib/dotnet/shared/Microsoft.AspNetCore.App/10.0.11/Microsoft.AspNetCore.Server.IIS.dll \
    | grep -c IIISEnvironmentFeature
0
# same version unpacked from the Microsoft runtime pack:
1

The distro build ships a ~17 KB resources-only stub in place of the real ~669 KB assembly. So
CoreServices' reference is fine against Microsoft's runtime and unresolvable against the distro one.
That would also explain #687 (RHEL 9, 10.0.8) — likewise a distro package.

Worth saying plainly since #687 frames it as the type being removed in .NET 10: as far as I can tell
it was not removed by Microsoft. I verified the type's presence in each assembly; I did not run the
app against a Microsoft-installed runtime, so the "works there" half rests on this issue's original
report plus my assembly evidence, not on my own end-to-end test.

Affected package versions

The reference appears in CoreServices from 1.3.2 onward, in every target (net8.0, net9.0,
net10.0). Determined by downloading each published package and scanning the assemblies. 1.0.0,
1.1.0 and 1.2.0 do not contain it, and a net10 host on 1.2.0 starts unpatched on the distro
runtime — though that is not a practical downgrade, since 1.2.0 predates
AddWrappedAspNetCoreSession and the System.Web.Hosting surface.

Workaround, for anyone stuck on a distro runtime

Four DI registrations match HostingRuntimeExtensions; exactly two need removing before
Build(). I enumerated all sixteen keep/remove subsets to find the minimum:

string[] doomed =
{
    "HostingRuntimeExtensions+HostingEnvironmentStartupFilter",
    "HostingRuntimeExtensions+EnvironmentFeatureConfigureOptions",
};

foreach (var d in builder.Services.Where(s => doomed.Any(
             n => s.ImplementationType?.FullName?.EndsWith(n, StringComparison.Ordinal) == true)).ToList())
{
    builder.Services.Remove(d);
}

The host then starts and serves requests, with HttpContext.Current and session working.

Keep the other two. DefaultAppPathConfigureOptions populates AppDomainAppPath, which
HttpContext.Current.Server.MapPath resolves through — removing it breaks path resolution for no
benefit. (I removed all four at first and lost exactly that.)

Cost: the removed startup filter is what initialises System.Web.Hosting.HostingEnvironment, so
the static HostingEnvironment.MapPath / ApplicationPhysicalPath then throw
InvalidOperationException. Server.MapPath is unaffected.

Suggested fix

Resolve the IIS environment feature lazily, or only when the IIS server is actually present, so the
type is never loaded on a non-IIS host. That would make the adapters robust to a runtime build that
trims the IIS assembly, regardless of who produced it.

---

Separately (happy to open its own issue if useful): AppDomainAppPath defaults to
AppContext.BaseDirectory, i.e. the build output. Under ASP.NET that value was the site root, so a
ported Server.MapPath("~/Templates/...") silently resolves under bin/ unless the host sets it to
the content root — no error, just a file that is never found.