When I recently upgraded from Spring.NET 1.1.0 to 1.1.1, I started getting a bizarre message:

DbProvider product name = Oracle, Oracle provider V2.102.2.20, could not resolve commandBuilderDeriveParametersMethod DeriveParameters to MethodInfo

It's looking for a method named DeriveParameters on the Oracle.DataAccess.Client.OracleCommandBuilder class.  Poking around with the .NET reflector, the method, sure enough, is not there.

After looking at some forum posts and a logged defect against Spring.NET, there were workarounds.  But surely with a database as common as Oracle these steps shouldn't be necessary!  No one having the issue was using Oracle, and, as it turns out, it's because they're using a newer driver that defines this magical DeriveParameters method.

I was using version 10.1.0.200, which is much newer than the 2.102.2.20 that Spring.NET expects when you look at the dbproviders.xml file.  But, alas, 10.1.0.200 is apparently code for something pre-2.102.2.20.  Oracle has two versioning schemes.  I found that when I downloaded the latest Oracle data access components (ODAC), billed as 11.1.0, I ended up with an Oracle.DataAccess.dll with a version 2.116.6.20 timestamp.  Happily, I found this to work with Spring.NET 1.1 without issue.

As a side note, I upgraded to NHibernate 1.2.1 from 1.2.0 at the same time and found the Oracle dialect suddenly dropped support for the "guid" data type.  Moral of the story:  even point releases have gotchas!