System.Data.SQLite

Static constructor of SQLiteFunction class reflects on all the assemblies which reference System.Data.SQLite.dll and registers all the functions defined in those assemblies. 

In order to inspect only assemblies that reference SQLite, the constructors compares the referenced assembly name with the calling assembly name.

System.Reflection.AssemblyName sqlite = System.Reflection.Assembly.GetCallingAssembly().GetName();
...
 for (int z = 0; z < t; z++)
            {
              if (references[z].Name == sqlite.Name)
              {
                found = true;
                break;
              }
            }

But its possible that the CLR calls the static constructor from an other assembly, therefore the calling assembly is not guaranteed to be SQLite assembly itself. Ran into this situation in a webapp. Notice in the following stacktrace SQLiteFunction's static constructor gets called from TestWebApp.dll, therefore only assemblies that reference TestWebApp.dll will be probed. Since since none of the assemblies reference TestWebApp.dll (Its the entry assembly) none of the user defined functions will be registered.

at System.Data.SQLite.SQLiteFunction..cctor() 
   at TestWebApp.Foo..ctor()
   at TestWebApp._Default..cctor() 
   at TestWebApp._Default..ctor()

I wrote a little more details in the post: http://fmansoor.wordpress.com/2013/08/06/sqlite-net-custom-functions-not-getting-registered-after-upgrading-to-net-4-5/ and also uploaded a test app I reproduced the problem in at github. https://github.com/faisalmansoor/SQLiteUserDefinedFunctions

The problem occur only in .Net 4.5 and in a ASP.Net web app. 

I think the fix should be easily fixed by just calling GetExecutingAssembly rather than GetCallingAssembly. Let me know if you guys have any questions etc.

Thanks.
Faisal

I'm looking into this now.

Fixed in trunk via check-in [80a4ab671c].