----- Original Message -----
From: "Nemanja Corlija" <[EMAIL PROTECTED]>
I'd be happy to see that list if its not a problem.
- Only one DLL to redistribute instead of two.
- Better side-by-side support. If multiple apps are using SQLite, there's
never any danger of them misbehaving because one app overwrote a sqlite3.dll
with a different version.
- You never have to worry whether a newer sqlite3.dll will work with an
older wrapper, or a newer wrapper will work with an older sqlite3.dll. For
example, checkin 3040 and several other sqlite checkins which changed the
behavior of API calls. Just copying the newer sqlite3.dll could've
potentially broken your app using an older wrapper. By combining them,
there's less opportunity for someone to accidentally screw something up.
- No need to maintain backward compatibility for each revision of the
wrapper against previous versions of sqlite3.dll. This keeps the wrapper
codebase streamlined. For example, when checkins 3062 and 3069 introduced
new API functionality, I was able to immediately rip out all the complex
code I had used to generate this information manually. I'd have had to
leave that in and used some conditional branching to maintain backward
compatiblity if the wrapper and core binary were separate.
- The core sqlite3 codebase is optimized for .NET interop, resulting in
significant speed gains with .NET.
- Compact Framework support. The sqlite.org's binary sqlite3.dll won't run
on CE, nor will a CE build of sqlite3.dll run with any .NET wrapper on CE
due to the interop restrictions in the Compact Framework. The only way to
get .NET and SQLite to play nice on the Compact Framework is to write
optimized interop entrypoints.
Robert
