An argument checking library

This is a ( single file ) library I wrote as an helper to check arguments validity.Here below a sample usage:

public class Demo
    {
        /// 
        /// Classical not null verification
        /// 
        /// 
        public void DoSomething(string arg1)
        {
            Contract.Expect(() => arg1).IsNotNull();
        }
        /// 
        /// Asserting an argument greather than another
        /// 
        /// 
        /// 
        public void DoSomething(int min,int max)
        {
            Contract.Expect(() => min)
                .IsLessThan(int.MaxValue)
                .Meet(a => a 
        /// Validate an integer argument in a certain range
        /// 
        /// 
        public void DoSomething(int arg1)
        {
            Contract.Expect(() => arg1).IsGreatherThan(0)
                                       .IsLessThan(100);
                ;

        }
        /// 
        /// Validate an array in length and asserts first element should be zero
        /// 
        /// 
        public void DoSomething(int[] array)
        {
            Contract.Expect(() => array).Meet(a => a.Length > 0 && a.First() == 0);
        }

    }

Exception message are auto generated based on the argument names, so we don't need magic strings at all. What about it ? Improvement and suggestions? Entire code is hosted here.

EDIT
just to clarify the pourpose of the library: I'm trying to avoid code such as:

if (stringParameter == null)
    throw new ArgumentNullException("stringParameter");

in which we need to write a string to specify the parameter name. This is not refactory friendly, neither DRY since you write twice "stringParameter" instead of:

Contract.Expect(() => stringParameter).IsNotNull();

That is once, and refactor friendly ( at least in my opinion ;) ).

Felice, can you expand on what you are looking for? Are you trying to infer constraints to be applied dynamically? I looked at your link to the whole code base at bitbucket.

First of all, nice work. Looks like you spent a good deal of time whipping that up.

On the surface, given your demo and not knowing what exactly your intended use case is, it appears 1) that you are trying to make constraints more visually fluent (which I appreciate) and 2) it seems "possibly" unneeded.

Once you further expand on your use case, I'm sure it will make more sense and I can revise my statements. However, for now let me explain item #2. 1) You can add the fluency you require by refactoring your code base into helper methods. 2) I would not really recommend throwing exceptions from what I can see. Given the code sample below (from your Contracts.cs) you are throwing an exception on something that should merely be a boolean check. As such you are altering the behavior of what you normally come to expect out of a programming language.

public IContract IsEqual(TT of) where TT : T,IEquatable
{
    TT actual = (TT)accessor();
    if (!actual.Equals(of))
    {
        throw new ArgumentOutOfRangeException(Name, "Must be equal to" + of.ToString());
    }
    return this;
}

3) I would recommend watching out for "re-inventing the language". Sometimes it is hard to identify, but the general smell is that you try to recreate basic functionality in the toolset you already use, instead of just using what you have. This can result in double/triple programming. Let's use the demo example from above (focusing on the snippet I grabbed). You have built several methods to provided the ".IsNotNull()" method for the Contract and are then encapsulating that (to make it more readable and fluent) into a method that just takes the parameter.

/// 
/// Classical not null verification
/// 
/// 
public void DoSomething(string arg1)
{
    Contract.Expect(() => arg1).IsNotNull();
}

instead of just:

if (arg1.IsNullOrEmpty())

or

if (arg1.IsNullOrWhiteSpace())

Which are already built into the .net framework.

I hope some/all of this helps. If you would, please further explain your use case. As for now, my recommendation would be to refactor your utility into static helper methods and not throw exceptions. For the error message part, just create helper method(s) to get the error message needed. So 1 method does the needed check and if it fails...and as a programmer you want to get the error message, you can choose to do that in a separate call.

StackExchange Code Review Q#10039, answer score: 2