icsharpcode/ILSpy · error · ReflectionNameParseException

Expected type name

Error message

Expected type name

What it means

ReflectionNameParseException thrown by ReadTypeNameSegment when it expects a type-name segment but finds a special character (or end of string) immediately at the current position (pos == start). It is reached indirectly through FindEntity -> ParseTypeNameParts whenever the type-name portion of an ID string is empty or starts with a separator/special character.

Source

Thrown at ICSharpCode.Decompiler/Documentation/IdStringProvider.cs:1083

		/// <summary>
		/// Reads a type name segment (no special characters). If allowDots is true,
		/// dots are included in the segment (for the top-level name which includes namespace).
		/// </summary>
		static string ReadTypeNameSegment(string typeName, ref int pos, bool allowDots)
		{
			int start = pos;
			while (pos < typeName.Length)
			{
				char c = typeName[pos];
				if (IsIDStringSpecialCharacter(c))
					break;
				if (!allowDots && c == '.')
					break;
				pos++;
			}
			if (pos == start)
				throw new ReflectionNameParseException(pos, "Expected type name");
			return typeName.Substring(start, pos - start);
		}

		/// <summary>
		/// Reads a type parameter count from the current position in an ID string.
		/// Handles both `n (unbound) and {T1,T2,...} (bound) syntax.
		/// For bound syntax, counts the arguments without fully parsing them
		/// (we only need the arity for type definition lookup).
		/// </summary>
		static int ReadTypeParameterCountFromIdString(string typeName, ref int pos)
		{
			if (pos >= typeName.Length)
				return 0;

			if (typeName[pos] == '`')
			{
				pos++;
				return ReflectionHelper.ReadTypeParameterCount(typeName, ref pos);

View on GitHub (pinned to 60c08fcb74)

Solutions

1. Ensure every type-name segment between dots is non-empty and contains no ID-string special characters.
2. Strip stray leading/trailing dots from the type portion before resolving.
3. Use GetIdString on a real entity to produce a well-formed ID string rather than building one by hand.

Example fix

// before
var e = IdStringProvider.FindEntity("T:.Foo.Bar", context);

// after
var e = IdStringProvider.FindEntity("T:Foo.Bar", context);

static bool LooksLikeTypeIdString(string s)
{
    if (s == null || s.Length < 2 || s[1] != ':') return false;
    string typePart = s.Substring(2);
    if (typePart.Length == 0) return false;
    var parts = typePart.Split('.');
    return parts.All(p => p.Length > 0);
}

try { return IdStringProvider.FindEntity(idString, context); }
catch (ReflectionNameParseException ex) { logger.Warn($"Malformed ID string at {ex.Position}: {ex.Message}"); return null; }

When it happens

Trigger: ID strings whose type portion has an empty segment: "T:.Foo" (leading dot in the type part), "T:Foo." (trailing dot producing an empty nested name), "T:{System.Int32}.Bar" (special '{' where a name is expected), or "T:" with nothing after.

Common situations: Hand-built or programmatically-constructed ID strings that drop a segment; crefs copied from external tooling that emit a leading/trailing dot or a brace where a name should be.

Related errors

• Missing type tag
• Could not find '.' separating type name from member name
• Expected '}'
• The handle must not be nil.
• Unsupported handle kind: {handle.Kind}

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