Лямбды с захваченными переменными

С технической точки зрения, правильный способ исправить это - использовать фреймворк, принимающий дерево выражений из лямбда-выражения для оценки ссылки i; другими словами, это ограничение платформы LINQ для какой-то конкретной платформы. В настоящее время он пытается интерпретировать i как членский доступ к некоторому типу, известному ему (поставщику) из базы данных. Из-за того, как работает захват лямбда-переменных, локальная переменная i на самом деле является полем в скрытом классе с забавным именем, которое провайдер не распознает.

Итак, это проблема фреймворка.

Если вам действительно нужно обойтись, вы можете создать выражение вручную, например:

ParameterExpression x = Expression.Parameter(typeof(RptCriteriaHint), "x");
var query = repo.Find(
    Expression.Lambda<Func<RptCriteriaHint,bool>>(
        Expression.Equal(
            Expression.MakeMemberAccess(
                x,
                typeof(RptCriteriaHint).GetProperty("CriteriaTypeID")),
            Expression.Constant(i)),
        x)).ToList();

... но это всего лишь мазохизм.

Ваш комментарий к этой записи побуждает меня к дальнейшим объяснениям.

Лямбда-выражения можно преобразовать в один из двух типов: делегат с правильной подписью или Expression<TDelegate> с правильной подписью. LINQ для внешних баз данных (в отличие от любых запросов в памяти) работает с использованием второго типа преобразования.

Компилятор преобразует лямбда-выражения в деревья выражений, грубо говоря, следующим образом:

1. Синтаксическое дерево анализируется компилятором - это происходит для всего кода.
2. Синтаксическое дерево переписывается с учетом захвата переменных. Захват переменных такой же, как в обычном делегате или лямбда-выражении - поэтому создаются классы отображения, а захваченные локальные переменные перемещаются в них (это то же поведение, что и захват переменных в анонимных делегатах C# 2.0).
3. Новое синтаксическое дерево преобразуется в серию вызовов класса Expression, так что во время выполнения создается дерево объектов, точно представляющее проанализированный текст.

Предполагается, что LINQ для внешних источников данных берет это дерево выражений и интерпретирует его на предмет его семантического содержания, а также интерпретирует символические выражения внутри дерева как относящиеся либо к вещам, специфичным для его контекста (например, столбцы в БД), либо как непосредственные значения для преобразования. Обычно System.Reflection используется для поиска специфичных для платформы атрибутов, направляющих это преобразование.

Однако похоже, что SubSonic неправильно обрабатывает символические ссылки, для которых он не может найти соответствия предметной области; вместо того, чтобы оценивать символические отсылки, это просто пантерация. Таким образом, это проблема SubSonic.