Question

We would like to parse expressions of the type:

Func<T1, bool>, Func<T1, T2, bool>, Func<T1, T2, T3, bool>, etc.

I understand that it is relatively easy to build an expression tree and evaluate it, but I would like to get around the overhead of doing a Compile on the expression tree.

Is there any off the shelf component which can do this?

Is there any component which can parse C# expressions from a string and evaluate them? (Expression services for C# , I think there is something like this available for VB which is used by WF4)

Edit:
We have specific models which on which we need to evaluate expressions which are entered by IT Administrators.

public class SiteModel
{
    public int NumberOfUsers {get;set;}
    public int AvailableLicenses {get;set;}
}

We would like for them to enter an expression like:

Site.NumberOfUsers > 100 && Site.AvailableLicenses < Site.NumberOfUsers

We would then like to generate a Func which can be evaluated by passing a SiteModel object.

Func<SiteModel, bool> (Site) => Site.NumberOfUsers > 100 && Site.AvailableLicenses < Site.NumberOfUsers

Also, the performance should not be miserable (but around 80-100 calls per second on a normal PC should be fine).

Answer 1

Thanks for your answers.

• Introducing a dependency on Mono in a product like ours (which has more than 100K installations and has a long release cycle of 1-1.5 years) may not be a good option for us. This might also be an overkill since we only need to support simple expressions (with little or no nested expressions) and not an entire language.
• After using the code dom compiler, we noticed that it causes the application to leak memory. Although we could load it in a separate app domain to work around this, this again might be an overkill.
• The dynamic LINQ expression tree sample provided as part of the VS Samples has a lot of bugs and no support for type conversions when ding comparisons (changing a string to an int, a double to an int, a long to an int, etc). The parsing for indexers also seems to be broken. Although not usable off the shelf, it shows promise for our use cases.

We have decided to go with expression trees as of now.