What causes "[{s_namespace}] {name} assembly not found" in microsoft/semantic-kernel?

Verify the assembly is not being trimmed or obfuscated in a way that strips GetType().Assembly.

microsoft/semantic-kernel · critical · KernelException

[{s_namespace}] {name} assembly not found

Error message

[{s_namespace}] {name} assembly not found

What it means

EmbeddedResource.Read calls typeof(EmbeddedResource).GetTypeInfo().Assembly to load embedded prompt/resource files bundled with the Orchestration.Flow experimental assembly. If that Assembly property returns null — a near-impossible condition under normal .NET runtime behavior — KernelException is thrown. This is effectively a runtime-environment failure, not a usage error.

Source

Thrown at dotnet/src/Experimental/Orchestration.Flow/EmbeddedResource.cs:15

// Copyright (c) Microsoft. All rights reserved.

using System.IO;
using System.Reflection;

namespace Microsoft.SemanticKernel.Experimental.Orchestration;

internal static class EmbeddedResource
{
    private static readonly string? s_namespace = typeof(EmbeddedResource).Namespace;

    internal static string? Read(string name, bool throwIfNotFound = true)
    {
        var assembly = typeof(EmbeddedResource).GetTypeInfo().Assembly ??
            throw new KernelException($"[{s_namespace}] {name} assembly not found");

        using Stream? resource = assembly.GetManifestResourceStream($"{s_namespace}." + name);
        if (resource is null)
        {
            if (!throwIfNotFound)
            {
                return null;
            }

            throw new KernelException($"[{s_namespace}] {name} resource not found");
        }

        using var reader = new StreamReader(resource);
        return reader.ReadToEnd();
    }
}

View on GitHub (pinned to c028a0c7dc)

Solutions

Verify the assembly is not being trimmed or obfuscated in a way that strips GetType().Assembly.
If using Native AOT / trimming, ensure the Orchestration.Flow assembly and its resources are preserved.
Re-deploy the application from a clean build to rule out corruption.
If this reproduces, report it as a runtime/hosting-environment issue rather than a code bug.

Defensive patterns

Strategy: try-catch

Validate before calling

// Not preventable via pre-call validation — it's a runtime condition.
// At startup, sanity-check that the assembly loads correctly:
var asm = typeof(EmbeddedResource).GetTypeInfo().Assembly;
if (asm is null)
    throw new InvalidOperationException("Runtime cannot resolve the Orchestration.Flow assembly.");

Try / catch

try { var content = EmbeddedResource.Read("prompts/config.txt"); }
catch (KernelException ex) when (ex.Message.Contains("assembly not found"))
{
    logger.LogCritical(ex, "Runtime environment cannot resolve the assembly. Possible trimming/AOT issue.");
    throw;
}

Prevention

If using Native AOT or IL trimming, add a DynamicDependency or rd.xml to preserve the assembly.
Test resource loading in the production host environment, not just in dev.
Do not obfuscate or strip the Orchestration.Flow assembly.

When it happens

Trigger: The CLR returns null for the assembly containing the EmbeddedResource type. This would require a severely broken assembly-load context, a stripped/obfuscated binary, or a reflection-only/unsupported hosting scenario.

Common situations: Running in a constrained or non-standard host (e.g., AOT with trimming that strips assembly metadata, a broken custom assembly resolver, or a corrupted deployment). This error is not expected in normal application usage.

Related errors

AI-assisted analysis of microsoft/semantic-kernel@c028a0c7dc (2026-08-13). Data as JSON: /api/errors/47bc3eafcee214c2. Report an issue: GitHub.