Skip to main content

How to Resolve Error "CS0853: An expression tree may not contain a named argument specification" in C#

The Compiler Error CS0853 is a limitation of the C# Expression Tree conversion logic. The message reads: "An expression tree may not contain a named argument specification".

In C#, you can call methods using Named Arguments (e.g., Method(paramName: value)), which frees you from remembering the exact order of parameters. However, Expression Trees (Expression<Func<...>>) are strictly structural. The underlying API (System.Linq.Expressions) maps arguments based entirely on their Position (Index 0, Index 1, etc.). It does not have the capability to store or process "parameter names" for method calls. Therefore, the compiler prohibits named arguments inside an expression lambda.

This guide explains how to convert named calls into positional calls to satisfy the Expression Tree requirements.

Understanding Positional vs. Named Arguments​

  • Standard C# (Compiler Magic): When you write Method(b: 2, a: 1), the compiler rearranges the inputs to match the method signature Method(int a, int b).
  • Expression Trees (Data Structure): An Expression Tree creates a MethodCallExpression node. This node contains a list of arguments. Argument 0 is always the first parameter defined in the method. Argument 1 is always the second. The tree has no mechanism to say "This argument belongs to parameter 'b'".

Because the mapping logic cannot be preserved in the tree, you must perform the mapping yourself (by ordering arguments correctly) in the code.

Scenario 1: Standard Method Calls​

This is the direct trigger. You are defining an Expression and trying to use the explicit name: value syntax for readability or reordering.

Example of error​

using System;
using System.Linq.Expressions;

public class Program
{
    public static void Calculate(int id, int value) { }

    static void Main()
    {
        // ⛔️ Error CS0853: An expression tree may not contain a named argument specification.
        // The compiler cannot encode "id:" or "value:" into the expression tree data.
        Expression<Action> expr = () => Calculate(id: 10, value: 50);
    }
}

Solution: Use Positional Arguments​

Remove the parameter names and ensure the values are in the exact order defined by the method signature.

using System;
using System.Linq.Expressions;

public class Program
{
    public static void Calculate(int id, int value) { }

    static void Main()
    {
        // ✅ Correct: Arguments passed by position (Order matters).
        // 10 maps to 'id' (first param), 50 maps to 'value' (second param).
        Expression<Action> expr = () => Calculate(10, 50);
    }
}

Scenario 2: Skipping Optional Parameters​

Named arguments are often used to skip optional parameters in the middle of a signature. Since Expression Trees forbid named arguments, they also implicitly forbid skipping optional parameters if doing so relies on names.

Example of error​

You want to set the third parameter, but rely on the default for the second parameter.

using System;
using System.Linq.Expressions;

public class Config
{
    public void Setup(string name, int retries = 3, bool isActive = true) { }
}

public class Program
{
    static void Main()
    {
        // ⛔️ Error CS0853: Cannot use 'isActive:' to skip 'retries'.
        Expression<Action<Config>> expr = c => c.Setup("MyConfig", isActive: false);
    }
}

Solution: Provide All Arguments​

You must manually provide the default value for the skipped parameter so that the positions align correctly.

using System;
using System.Linq.Expressions;

public class Config
{
    public void Setup(string name, int retries = 3, bool isActive = true) { }
}

public class Program
{
    static void Main()
    {
        // ✅ Correct: We manually supply '3' (the default) for the second argument
        // so that 'false' correctly falls into the third position.
        Expression<Action<Config>> expr = c => c.Setup("MyConfig", 3, false);
    }
}
note

Expression Tree Limitations: Not only are named arguments forbidden, but Optional Parameters are also not natively supported in Expression Trees. The compiler forces you to bake the default value explicitly into the call site (as shown above) because the concept of "Default" doesn't exist in the simple MethodCallExpression node.

Conclusion​

CS0853 is a strict formatting rule for Expression Trees.

  1. Check Syntax: Look for the colon : in argument lists (e.g., arg: val).
  2. Remove Names: Delete the argument names.
  3. Check Order: Verify that your values match the order of the method parameters exactly.
  4. Fill Defaults: If you were using names to skip optional parameters, you must now explicitly provide values for those skipped parameters.

Table of Contents