An argument checking library
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&lt;T&gt; IsEqual&lt;TT&gt;(TT of) where TT : T,IEquatable&lt;TT&gt;
{
    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.

/// &lt;summary&gt;
/// Classical not null verification
/// &lt;/summary&gt;
/// &lt;param name="arg1"&gt;&lt;/param&gt;
public void DoSomething(string arg1)
{
    Contract.Expect(() =&gt; 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.