Sqlite is a public domain database engine written in C. There is no managed version of the code that provides ado.net functionality. The ado.net providers that you see for Sqlite are all third party add ons or forks from the core engine. The engine itself is C code, and has a surprising number of variants present in the real world.

Not 100% Managed Code

Sqlite is unmanaged C code at the core. There are managed wrappers around that code, but they cannot auto promote between 32 and 64 bit, or across .Net runtimes because of the unmanaged code. VistaDB can load in .Net 2 through .Net 4, with both 32 and 64 bit supported - all in a single dll.

No Tools Included

Sqlite does not include any GUI DBA tools for building your database, again you have to go to a third party in order to find that functionality. The Sqlite core is just an unmanaged dll, it does not include ado.net or anything related to .Net programming. You have to find a third party that is building that functionality.

Lack of central build authority causes problems

Sqlite can be compiled with many different options (PThreads, FK enforcement, 32 or 64 bit, etc), this means there is no way to guarantee the version in the system path is even compatible with what you need. This is what was commonly referred to as DLL Hell for unmanaged programmers. Since there is no central authority on what constitutes an official release you may be running someones slightly altered version they embedded into a provider without really knowing it.

While Dll Hell is not completely gone from the world of .Net programming, .Net does provide a strongly named version for each assembly to ensure that only the version you want is loaded. This version loading includes the dll name, it's strongly named key, and the complete File Version. Two versions of VistaDB (4.0 and 4.1 for example) can be present in the GAC at the same time and calling applications get the version they are expecting. We go to great lengths to ensure that all exact matching assembly loads will be compatible. If we introduce a breaking change we will always bump the version number to avoid accidental loads by applications expecting the older behavior.

Apple was recently bit by this when they put their version of Sqlite in the \windows\system32 directory with iTunes. But if another Sqlite dll is already present with a higher number, the dll is not copied by the Windows Installer.

Google Adwords desktop version was also hit by this. The desktop adwords tool had the Sqlite dll replaced by a third party update and it broke the Google Adwords due to an interface change in the dll by that third party.