Harden diagnostics when integration-assembly resolver discovers zero contributors

[IEvangelist]

Note

Updated 2026-05-04: The originally-reported 13.3.0 reproduction is no longer reproducible after clearing ~/.nuget and ~/.aspire on the reporter''s machine. The symptom appears to have been a stale local NuGet cache anomaly — the reporter had been switching between PR / staging / stable 13.3.0 builds, and a package on disk versioned 13.3.0 carried inconsistent contents relative to the rest of the 13.3.0 set. So this is not a release/13.3 ship blocker.

This issue is repurposed to track the diagnostic hardening so that any future failure with the same symptom (cache anomaly, build-pipeline skew, transitive package mismatch, partially populated probe directory, etc.) is loud and self-explanatory instead of producing only the cryptic surface error.

Symptom

aspire new with a TypeScript template fails before any project files are scaffolded:

• Empty (TypeScript AppHost) → ❌ An unexpected error occurred: No language support found for: typescript/nodejs
• Starter App (Express/React, TypeScript AppHost) → ❌ An unexpected error occurred: No code generator found for language: TypeScript

Both errors come out of the apphost RPC server (aspire-managed.exe server):

• LanguageService.ScaffoldAppHost
• CodeGenerationService.GenerateCode

Why this is bad

When the resolver fails, the user sees a one-line cryptic error and nothing else. The actual failure mode (e.g., ReflectionTypeLoadException from assembly.GetTypes(), or a successful load that contributes zero discoverable types) is logged at LogDebug, which is below the file logger''s default Information threshold and never reaches the CLI''s on-disk log. So the user has no path to self-diagnose.

What we''re doing about it

PR #16733 hardens the diagnostic chain at every layer:

1. CodeGeneratorResolver / LanguageSupportResolver log ReflectionTypeLoadException at Warning level and include the LoaderExceptions text.
2. When an assembly named like Aspire.Hosting.CodeGeneration.* is loaded but contributes zero ICodeGenerator / ILanguageSupport types, a Warning is logged so the silent-failure case is visible.
3. AssemblyLoader.LoadAssemblies performs an Aspire.TypeSystem version sanity check against the libs directory at startup and warns on mismatch.
4. LanguageService / CodeGenerationService error messages now list the available languages, or point at the apphost-server log + binary mismatch when zero have been discovered.
5. PrebuiltAppHostServer promotes apphost-server stdout/stderr capture from Trace to Debug / Information, so warnings emitted by the apphost server actually reach the default file log.

After this lands, a recurrence of the original symptom would surface a clear log entry naming the offending assembly and the version mismatch (or the swallowed ReflectionTypeLoadException), making the underlying cause obvious to both the user and to support.

Original report (preserved for context)

CLI version + invocation that produced the symptom

aspire --version
13.3.0+ee860bda2a0c813a9a07b26aa988ae7c279d5562

aspire new
# Select template: Empty (TypeScript AppHost)
# ...
# ❌ An unexpected error occurred: No language support found for: typescript/nodejs

aspire new
# Select template: Starter App (Express/React, TypeScript AppHost)
# ...
# ❌ An unexpected error occurred: No code generator found for language: TypeScript

aspire new aspire-ts-empty --name empty-ts --output ./empty-ts --localhost-tld true --non-interactive
aspire new aspire-ts-starter --name favs --output ./favs --localhost-tld true --non-interactive

Investigation summary

End-to-end trace against the reporter''s machine confirmed:

1. The required Aspire.Hosting.CodeGeneration.TypeScript.dll (and full transitive closure) was on disk at ~/.aspire/packages/restore/<hash>/libs/.
2. Reflection-only inspection showed both AtsTypeScriptCodeGenerator : ICodeGenerator (Language = "TypeScript") and TypeScriptLanguageSupport : ILanguageSupport (Language = "typescript/nodejs") with public parameterless constructors.
3. The apphost server''s bundle-hosts/<hash>/appsettings.json listed the assembly correctly under AtsAssemblies.
4. AssemblyLoader did load the assembly into the IntegrationLoadContext (confirmed by capturing the inner-process stdout via a wrapper exe with Logging__LogLevel__Default=Debug).
5. AtsContext discovery on the loaded assembly succeeded (hundreds of [ATS] Discovered: ... entries).
6. A standalone reproducer with the same IntegrationLoadContext shape against the same libs directory did find both types.

Yet inside the bundled aspire-managed.exe, both resolvers returned null. The most plausible explanations were a type-identity mismatch on Aspire.TypeSystem.ILanguageSupport / ICodeGenerator between the bundled and probed Aspire.TypeSystem copies, or a ReflectionTypeLoadException whose surviving ex.Types happened to omit those two types — both invisible to the user because the resolver swallowed the exception at LogDebug and the file logger filtered it out.

After clearing ~/.nuget and ~/.aspire, the failure stopped reproducing, consistent with a stale-cache anomaly. Diagnostic hardening (this issue) is the durable fix.

Suspected locations (now instrumented by #16733)

• src/Aspire.Hosting.RemoteHost/Language/LanguageSupportResolver.cs
• src/Aspire.Hosting.RemoteHost/CodeGeneration/CodeGeneratorResolver.cs
• src/Aspire.Hosting.RemoteHost/IntegrationLoadContext.cs
• src/Aspire.Hosting.RemoteHost/AssemblyLoader.cs
• src/Aspire.Cli/Projects/PrebuiltAppHostServer.cs

[IEvangelist]

✅ Definitive root cause: assembly-version mismatch between bundled and libs assemblies

Following @bradygaster's suggestion to look at the folder layout and assembly versions, I dumped the actual identities of the relevant assemblies. There is a clear mismatch.

The bundled aspire-managed.exe (default ALC)

From aspire-managed.deps.json (extracted via COREHOST_TRACE=1):

Processing package Aspire.Hosting.RemoteHost/13.3.0
    Aspire.Hosting.RemoteHost.dll  assemblyVersion=13.3.0.0  fileVersion=13.300.26.25109
Processing package Aspire.TypeSystem/13.3.0
    Aspire.TypeSystem.dll          assemblyVersion=13.3.0.0  fileVersion=13.300.26.25109

Bundled Aspire.TypeSystem identity: Aspire.TypeSystem, Version=13.3.0.0.

The libs assemblies (IntegrationLoadContext)

From ~/.aspire/packages/restore/F503CA145125F83A/libs (read with MetadataLoadContext):

File	AssemblyVersion	FileVersion	InformationalVersion	MVID
Aspire.TypeSystem.dll	42.42.42.42	42.42.42.42424	13.3.0	4f45493f-e47e-4340-87a3-a8d8ed73f0f8
Aspire.Hosting.dll	42.42.42.42	42.42.42.42424	13.3.0	c3790ecb-4d76-478c-b8bb-08444730f972
Aspire.Hosting.CodeGeneration.TypeScript.dll	42.42.42.42	42.42.42.42424	13.3.0	af9c91c8-af5f-42ff-bda5-0cc60bbab073

Note also that aspire-managed.exe has AssemblyInformationalVersionAttribute = 13.3.0+ee860bda2a0c813a9a07b26aa988ae7c279d5562 (full SourceLink commit), while the libs DLLs have AssemblyInformationalVersionAttribute = 13.3.0 (no commit suffix). The libs were built from a different toolchain/configuration than the bundled exe even though both are stamped 13.3.0 at the package level.

The pinned reference

The crucial bit — the libs's Aspire.Hosting.CodeGeneration.TypeScript.dll has a single Aspire reference:

Aspire.Hosting.CodeGeneration.TypeScript, Version=42.42.42.42:
  references → Aspire.TypeSystem, Version=42.42.42.42, PublicKeyToken=cc7b13ffcd2ddd51

So when IntegrationLoadContext loads Aspire.Hosting.CodeGeneration.TypeScript.dll and the JIT walks TypeScriptLanguageSupport to resolve its base interface ILanguageSupport, the runtime asks for Aspire.TypeSystem, Version=42.42.42.42. Per IntegrationLoadContext.cs:31-40, Aspire.TypeSystem is hard-coded as a "shared assembly" that always defers to the default ALC. The default ALC only has the bundled Aspire.TypeSystem, Version=13.3.0.0. 42.42.42.42 ≠ 13.3.0.0 → the bind fails → TypeScriptLanguageSupport and AtsTypeScriptCodeGenerator come back as null in ReflectionTypeLoadException.Types.

Why no error reaches the user

LanguageSupportResolver.DiscoverLanguages and CodeGeneratorResolver.DiscoverGenerators both have:

catch (ReflectionTypeLoadException ex)
{
    _logger.LogDebug(ex, "Some types in assembly '{AssemblyName}' could not be loaded", assembly.GetName().Name);
    types = ex.Types.Where(t => t is not null).ToArray()!;
}

The exception is logged at Debug level, but the apphost server runs at Information level by default and its stdout/stderr aren't surfaced into the CLI's on-disk log (see #16729 description point 2). So the user gets a single line — No code generator found for language: TypeScript / No language support found for: typescript/nodejs — with the LoaderExceptions buried.

Why my standalone reproducer didn't fail

In the standalone reproducer I built earlier (a console app loading the same Aspire.Hosting.CodeGeneration.TypeScript.dll through a custom ALC against the same libs path), Aspire.TypeSystem.dll is loaded into the default ALC from disk, so the type is Aspire.TypeSystem, Version=42.42.42.42 — matching the reference exactly. Discovery succeeds. The only difference between repro and the bundled exe is the version of Aspire.TypeSystem provided by the default ALC.

Why this is a 13.3.0 staging-feed problem (not user-environmental like #16601)

The package source for the apphost restore is the per-commit staging feed:

https://pkgs.dev.azure.com/dnceng/public/_packaging/darc-pub-microsoft-aspire-ee860bda/nuget/v3/index.json

That feed's Aspire.TypeSystem.13.3.0.nupkg, Aspire.Hosting.13.3.0.nupkg, and Aspire.Hosting.CodeGeneration.TypeScript.13.3.0.nupkg all contain DLLs stamped with the placeholder Version=42.42.42.42 instead of the proper 13.3.0.0. That looks like a build-pipeline regression where OfficialBuildId / Version stamping ran for the CLI exe but not for the NuGet packages, even though both ended up with the same 13.3.0 package version.

Aspire.Hosting.CodeGeneration.TypeScript.13.3.0 is not on nuget.org (only 13.2.x is published), and Aspire.Hosting.13.3.0 isn't on nuget.org either, so the only place the 13.3.0 packages exist is on the staging feed — and the staging feed's copies are mis-stamped.

Suggested fixes

1. Build pipeline (primary): Ensure assembly version stamping on the staging-feed Aspire.*.13.3.0 NuGet packages — they should report assemblyVersion=13.3.0.0 like the CLI bundle, not 42.42.42.42.
2. Resolver visibility (secondary): Promote the LogDebug(ex, ...) in both resolvers to LogWarning (or at least LogInformation) so loader binding failures don't disappear into Debug-level oblivion. Today a user has no way to discover the LoaderExceptions without rebuilding the bundle.
3. IntegrationLoadContext resilience: Even with a correct shared-assembly contract, version drift between bundled and libs Aspire.TypeSystem can recur. Consider name-only matching for Aspire.TypeSystem (already its current intent) plus a startup probe that compares the bundled and libs Aspire.TypeSystem MVIDs and fails fast with a clear message if they differ.
4. Test coverage: Add an end-to-end test that exercises the resolver path against a published, single-file aspire-managed.exe plus a libs directory built independently (different build configuration), so this category of mismatch is caught.

cc @bradygaster — your "look at the folder + assembly versions" hunch was the key.

[mitchdenny]

@IEvangelist is this something we want for 13.4? Looks like you had a closed PR on it?