System.Data.SQLite
View Ticket
Not logged in
Ticket UUID: 4e49a58c4c99dff2092bc8f7d944cc273918bfab
Title: Custom functions don't get registered
Status: Closed Type: Code_Defect
Severity: Important Priority: Blocker
Subsystem: Custom_Function Resolution: Fixed
Last Modified: 2013-08-07 03:52:32
Version Found In: 1.0.87.0
User Comments:
anonymous added on 2013-08-06 19:24:50:
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

mistachkin added on 2013-08-06 20:14:00:
I'm looking into this now.

mistachkin added on 2013-08-07 03:52:32:
Fixed in trunk via check-in [80a4ab671c].