NeinLinq rewrites your LINQ calls into expressions the provider can translate

The problem: a helper method the ORM cannot translate

Most LINQ providers, Entity Framework among them, can only handle a small subset of .NET functionality. The README puts it plainly: many LINQ providers can only support a very minor subset of .NET functionality, they even cannot support our own functions.

The example is a method called LimitText that truncates a string to a maximum length. Use it inside an ordinary LINQ query and the provider refuses, with the message that LINQ to Entities does not recognize the method System.String LimitText(System.String, Int32), and that this method cannot be translated into a store expression.

The consequence described is worse than a single failing query. Logic has to be scattered between code that any LINQ provider will translate and code that will not, and when some logic is translatable it has to be copied and pasted. Consolidating the code within an ordinary function does not work, because the provider cannot translate the call in the first place.

That is the exact problem NeinLinq attacks. It is aimed at codebases where reusable helpers are shared between an in-memory LINQ path and a database path, and where the database path keeps breaking because the helper is not on the provider's list of supported operations.

Lambda injection: replacing a call with an expression the provider understands

The mechanism is a rewrite engine. A query is marked as injectable, and a method used inside it is marked as injectable too, and then the engine replaces the method call with a matching lambda expression that the provider can translate into SQL.

The convention is that a method carries the attribute and also exposes a parameterless overload returning the expression that stands in for it:

[InjectLambda]
public static string LimitText(this string value, int maxLength)
{
    if (value != null && value.Length > maxLength)
        return value.Substring(0, maxLength);
    return value;
}

public static Expression<Func<string, int, string>> LimitText()
{
    return (v, l) => v != null && v.Length > l ? v.Substring(0, l) : v;
}

The ordinary method is the one that runs against in-memory objects, so it has to work on its own. The expression overload is what gets spliced into the query. The rewrite happens because the query was marked injectable with ToInjectable(), and the call to ToInjectable can appear anywhere in the LINQ chain, so business logic does not have to be polluted with it.

What this buys is that one implementation of a helper serves both worlds. The same LimitText is used in a plain LINQ query over a list and inside an Entity Framework query, and the second one is translated rather than rejected.

Three packages, three different method names

NeinLinq is not a single package. Because it supports different LINQ implementations, the README says to choose at least one of three flavours, and each has a different set of extension method names to avoid conflicts.

The plain package is for ordinary LINQ queries:

PM> Install-Package NeinLinq

The Entity Framework 6 package is for EF6 queries:

PM> Install-Package NeinLinq.EntityFramework

And the Entity Framework Core package is for EF Core:

PM> Install-Package NeinLinq.EntityFrameworkCore

The consequence is visible in the names. ToInjectable belongs to NeinLinq, ToDbInjectable to NeinLinq.EntityFramework, and ToEntityInjectable to NeinLinq.EntityFrameworkCore. A codebase that starts on plain LINQ and later moves to EF Core has a rename across every query, which is mechanical but not free.

There is also a correctness point attached to the choice. The README says usage of the specific flavours is encouraged for EF6 and EF Core, otherwise async queries will not work. That is the kind of detail that turns into a confusing production bug if you install the base package on an EF Core project by accident.

The packages ship on NuGet under the NeinLinq name, and the repository contains the solution file nein-linq.slnx, a shared build.props and pack.props, a global.json, a nuget.config, and a strong name key file nein-linq.snk.

Turning lambda injection on globally for EF Core

Since version 5.1.0, the Entity Framework Core package offers an explicit DbContext extension that enables lambda injection globally, so you do not have to mark every query as injectable:

    services.AddDbContext<MyContext>(options =>
         options.UseSqlOrTheLike("...").WithLambdaInjection());

The README attaches one condition to that call, and it is easy to get wrong: the call to WithLambdaInjection needs to happen after the call to UseSqlOrTheLike.

That ordering constraint exists because the lambda injection machinery has to be attached to the provider configuration rather than to the context object, so it can only be installed once the provider has been chosen. Calling it in the other order means there is no provider yet to attach to.

For a project where most queries benefit, this removes the ToEntityInjectable call from every query chain. For a project where only some queries contain injectable helpers, the per-query approach keeps the blast radius small, since a query that is not marked injectable is simply left alone by the rewrite engine.

Injecting code you cannot edit, and writing your own expressions

The second half of the library is about not having to modify the code you use.

Since version 7.0.0, NeinLinq supports custom providers for the InjectLambdaAttribute. The point is to define your own logic for deciding which methods count as injectable, without adding the attribute to each one, which the README says is particularly useful when working with external libraries or code you cannot modify directly:

var oldProvider = InjectLambdaAttribute.Provider;

InjectLambdaAttribute.SetAttributeProvider(memberInfo =>
{
    // Your custom logic here
    if (memberInfo.Name.StartsWith("ExternalMethod"))
    {
        return new InjectLambdaAttribute(typeof(MyType), nameof(MyType.ExternalMethodExpression));
    }
    // fallback to standard provider
    return oldProvider(memberInfo);
});

The pattern in that snippet is the whole idea. A method called ExternalMethod on some type is mapped to a separate expression, ExternalMethodExpression, which the provider can translate. The original method stays untouched and the expression lives somewhere you control.

There is a second convention for cases where you would rather not write the attribute at all: the same class, same name, matching signature. The method is then picked up automatically, provided the class has been green listed. The README also notes that the ordinary method can just compile the expression, ideally only once, so the duplication between the two forms does not have to be maintained by hand.

Where the approach stops working, and how it differs from the alternatives

The limitation is structural and worth stating before anyone invests in it. The injected expression has to be something the LINQ provider can translate into SQL. That is fine for LimitText, which is a substring operation, and fine for a Like helper implemented on top of SqlFunctions.PatIndex. It is not fine for a helper that loops over a collection, calls a method the provider has never heard of, or depends on state that has no representation in a store expression.

So the pattern is a way to publish helpers the provider can express, not a way to make arbitrary code translatable. A helper that cannot be expressed as a lambda over the same inputs has no injected form, and the rewrite engine has nothing to substitute.

There is a second cost, visible in the examples themselves. The ordinary methods in the README throw NotImplementedException, because the direct implementation is not the one that runs in a database query. That is a workable pattern, but it means the method you call and the method that executes are two different things, and the two can drift apart if someone edits one of them.

The alternatives differ in approach rather than in degree. Writing raw SQL fragments or stored procedures keeps the logic in the database, where it is fully expressible, and costs you the ability to reuse the same helper in an in-memory LINQ path. Evaluating in memory after pulling the rows out, the approach of pulling rows out with ToList and then filtering, keeps the helper untouched and removes the translation problem, at the cost of moving rows you did not need. NeinLinq sits between the two: it keeps the helper in C#, keeps it in the query, and requires only that a translatable expression exists for it.

For a team already living with hand-written SQL for the hard parts, NeinLinq is not going to replace that. It is aimed at the ordinary case, where a small set of helpers keeps failing to translate and each one costs a workaround.

Editorial conclusion

Adopt NeinLinq if your Entity Framework queries are full of helper methods the provider refuses to translate, and the logic in those methods is simple enough to be expressed as a lambda. Do not adopt it for complex algorithms, since the injected expression has to be something the provider can translate, and be careful with the package flavour, because the extension method names differ between NeinLinq, NeinLinq.EntityFramework and NeinLinq.EntityFrameworkCore and the README warns that async queries do not work if you pick the wrong one. Before you commit, check the last push on 2026-10-17 and the latest release v7.4.0 from 2025-11-13, and read the section on the same class, same name, matching signature convention, since it requires the class to be green listed. The licence is MIT.

Frequently asked questions

Official sources

1. axelheer/nein-linq on GitHub
2. Issues
3. License: MIT
4. README
5. Releases