There is a recent MSDN article that outlines SPOIL.  It is an acronym for Stored Procedure Object Interface Library. 

I think it is a pretty cool concept that could be potentially very useful in specific situations.  To a certain degree, SPOIL reduces the amount of code required for stored procedure invocation.  Rather than manually creating each parameter, the library will do this for you.  Of course, the same effect can be achieved using the Data Application Block provided by Microsoft.  But, the Application Block is lacking in one particular area where SPOIL really shines...strongly typed stored procedure parameters.  The ability to strongly type stored procedures is very compelling.  There have been numerous instances where a compile time verification of types would have saved me some headaches. 

However, there are a couple of things to keep in mind.  The use of reflection does impose a minor performance penalty that should be considered before jumping in with both feet, particularly in systems and applications that demand an extremely high level of performance.  Even though reflection has dramatically improved in 2.0, there is still a penalty, even if it is miniscule.  In addition, the current implementation relies on the use of read-write properties.  If you require persisting/loading values to read-only and write-only properties or private member variables, you will have to defer to traditional stored procedure invocation or extend the library to suit your needs.

Overall, it is an interesting concept to keep in your programming arsenal for the right occasion.