icsharpcode/ILSpy · error · NotSupportedException

Type {fullTypeName} was not found in the module being decomp

Error message

Type {fullTypeName} was not found in the module being decompiled, but only in {type.ParentModule!.Name}

What it means

Thrown by DecompileType(FullTypeName) as NotSupportedException when the type resolves but its ParentModule is not the main module the CSharpDecompiler was built for. Decompiling a type from a referenced dependency is unsupported; only types owned by the decompiled module can be emitted.

Source

Thrown at ICSharpCode.Decompiler/CSharp/CSharpDecompiler.cs:1333

		public string DecompileTypesAsString(IEnumerable<TypeDefinitionHandle> types)
		{
			return SyntaxTreeToString(DecompileTypes(types));
		}

		/// <summary>
		/// Decompile the given type.
		/// </summary>
		/// <remarks>
		/// Unlike Decompile(IMemberDefinition[]), this method will add namespace declarations around the type definition.
		/// Note that decompiling types from modules other than the main module is not supported.
		/// </remarks>
		public SyntaxTree DecompileType(FullTypeName fullTypeName)
		{
			var type = typeSystem.FindType(fullTypeName.TopLevelTypeName).GetDefinition();
			if (type == null)
				throw new InvalidOperationException($"Could not find type definition {fullTypeName} in type system.");
			if (type.ParentModule != typeSystem.MainModule)
				throw new NotSupportedException($"Type {fullTypeName} was not found in the module being decompiled, but only in {type.ParentModule!.Name}");
			var decompilationContext = new SimpleTypeResolveContext(typeSystem.MainModule);
			var namespaces = new HashSet<string>();
			syntaxTree = new SyntaxTree();
			RequiredNamespaceCollector.CollectNamespaces(type.MetadataToken, module, namespaces);
			var decompileRun = CreateDecompileRun(namespaces);
			DoDecompileTypes(new[] { (TypeDefinitionHandle)type.MetadataToken }, decompileRun, decompilationContext, syntaxTree);
			RunTransforms(syntaxTree, decompileRun, decompilationContext);
			return syntaxTree;
		}

		/// <summary>
		/// Decompile the given type.
		/// </summary>
		/// <remarks>
		/// Unlike Decompile(IMemberDefinition[]), this method will add namespace declarations around the type definition.
		/// </remarks>
		public string DecompileTypeAsString(FullTypeName fullTypeName)
		{

View on GitHub (pinned to 60c08fcb74)

Solutions

  1. Check def.ParentModule == decompiler.TypeSystem.MainModule before calling DecompileType.
  2. If you really need that type, construct a separate CSharpDecompiler over the assembly where it is actually defined.

Example fix

// before
var tree = decompiler.DecompileType(name); // name lives in a referenced assembly

// after
var def = decompiler.TypeSystem.FindType(name.TopLevelTypeName).GetDefinition()
    ?? throw new InvalidOperationException($"'{name}' not found");
if (def.ParentModule != decompiler.TypeSystem.MainModule)
    throw new InvalidOperationException($"'{name}' is in {def.ParentModule.Name}; decompile that module instead");
var tree = decompiler.DecompileType(name);
Defensive patterns

Strategy: validation

Validate before calling

var def = decompiler.TypeSystem.FindType(name.TopLevelTypeName).GetDefinition()
    ?? throw new InvalidOperationException($"'{name}' not found");
if (def.ParentModule != decompiler.TypeSystem.MainModule)
    throw new InvalidOperationException($"'{name}' is in {def.ParentModule.Name}; load and decompile that module instead");
var tree = decompiler.DecompileType(name);

Prevention

When it happens

Trigger: The FullTypeName resolves to a type the type system found in a referenced assembly rather than the module under decompilation. Common with type forwarding (TypeForwardedTo) or names shared across assemblies.

Common situations: Decompiling app A and asking for a type A only references from a framework DLL; type forwarding making the type resolve in another module.

Related errors


AI-assisted analysis of icsharpcode/ILSpy@60c08fcb74 (2026-08-13). Data as JSON: /api/errors/7ddfba59f7038822. Report an issue: GitHub.