Are you using NuGet or downloading the binaries from System.Data.Sqlite.org?
Ah. You'll have to excuse me, it's been a while since I actually started a new project and set SQLite as a dependency. I'm not sure if things have changed, or if my memory is terrible, but what I said may not have been completely clear or correct. If you're using NuGet (the easiest way): Turns out there's a NuGet package called System.Data.Sqlite.Core* that includes only the core SQLite wrapper. If you install System.Data.Sqlite you get the LINQ and EF stuff (which I generally try to stay away from). If you use this package you will get both the x64 and x86 interop binaries in their respective folders. If you have already installed the System.Data.Sqlite package, and got the LINQ and EF dependencies, you should be able to remove them as a dependency by right clicking the the unnecessary dependencies to open their context menu, and selecting "Remove". If you're downloading from the website System.Data.Sqlite.org: You only get an x86 or a x64 version of the interop binaries, depending on what you download. The download page has some instructions on how you can make the wrapper library automatically select the correct interop dll for whichever architecture you're targetting. See the section entitled "Native Library pre-loading". I haven't gone through this setup personally so cannot help you any more than what is there on the site (The NuGet package comes with this preconfigured). You can choose to download the mixed mode assemblies which will not have the 'interop' DLLs. I haven't played around with these because the download page specifically advises to avoid these packages unless you need to put SQLite in the Global Assembly Cache (which the authors also recommend against). Note that if you download from the website, you'll get the LINQ and EF6 dlls included in the zip file. If you never reference them from your project, they won't be copied to your output directory and you can ignore them. Hope this helps. I am by no means an expert, I've only messed with it a few times. I hope that if I have got things wrong that someone more experienced can jump in and correct my mistakes. * This name might be a little confusing since Microsoft have recently release an unrelated product called Entity Framework Core. It appears unrelated to System.Data.Sqlite.Core. On 21 February 2017 at 13:48, Clyde Eisenbeis <cte...@gmail.com> wrote: > Thanks for the good info! > > I can't find SQLite.Interop.dll ... is referenced at > https://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki, > but don't see a download. > > On Mon, Feb 20, 2017 at 12:30 PM, Barry Smith <smith.bar...@gmail.com> > wrote: > > I would use system.data.sqlite in that situation. > > > > But I would also say it depends on what you already have written, and > what your strengths are. I am under the impression from your first email > that you already have something written using system.data.sqlite. i.e. > Using the class System.Data.SQLite.SQLiteConnection to create a > connection to the db, then using the methods of that to manipulate the db > or extract data from it. Have I assumed wrong? > > > > If I am wrong, and you have yet to start writing anything, I would still > recommend using system.data.sqlite. Only if you particularly like LINQ over > SQL and you are prepared to learn the caveats of the entity framework would > I recommend that. > > > > Note that if you're using system.data.sqlite you will ultimately produce > a few dlls that must be distributed together: > > - your custom library, which contains the code you've written > > - System.Data.Sqlite.dll, which contains the wrapper to make an > interface to access SQLite in a more dotNet friendly manner > > - x64\sqlite.interop.dll > > - x86\sqlite.interop.dll > > The last two contain the 'raw' SQLite library (for either 32 or 64 bit > systems). > > > > You should not need the other libraries for a simple application. If you > find that visual studio is placing them in your project's output directory, > check if they are listed as a reference and try to remove them then > recompile. > > > >> On 20 Feb 2017, at 1:05 PM, Clyde Eisenbeis <cte...@gmail.com> wrote: > >> > >> Thanks for the clarification. In my case: > >> > >> 1) Speed is not an issue. Size is not an issue. > >> > >> 2) This is a personal use database (genealogy). > >> > >> 3) Typically I create .dll's that serve as a library (WPF Custom > >> Control Library) ... easy to use for different programs. > >> > >> 4) For example, I have an Excel .dll library (uses Excel as a > >> database). When the program runs the first time using this .dll > >> library, it creates the Excel file along with multiple sheets. > >> > >> 5) I'd like to create a similar .dll for an SQLite library. The > >> program that uses this .dll is a simple WPF program that uses the .dll > >> class name to access the functions. > >> > >> With this info, which option would you recommend? > >> > >>> On Sun, Feb 19, 2017 at 9:45 PM, Barry Smith <smith.bar...@gmail.com> > wrote: > >>> Strange, I replied to this earlier... Perhaps my messages are not > getting through. > >>> > >>> You cannot include a .c file for compilation in a c# project. You'd > have to do use a separate DLL and do some pinvoke stuff to get to the raw > SQLite interface, but in my opinion you're better off using the > system.data.sqlite wrapper. If you need the speed and power of the raw > interface, you probably need to drop out of an interpreted and managed > language (c#) too... > >>> > >>> You don't need the entity framework (EF) to run system.data.sqlite. > That is an object relational mapper (ORM) that uses a lot of fancy > reflection to make data access a little easier* (until you get stung by it) > and a lot slower. EF is developed my Microsoft, although SQLite must > provide some input to make it work with its syntax. You should be able to > remove the entity framework dependencies from your project and still > compile with no issues. Try a complete rebuild / clean compile to try get > rid of the unnecessary dlls. > >>> > >>> *whether an ORM actually makes data access easier is debatable, they > basically allow you to write your data access queries in LINQ rather than > SQL, and automatically instansiate c# objects for each line in the results. > I find SQL easier... > >>> > >>>> On 19 Feb 2017, at 1:50 PM, Clyde Eisenbeis <cte...@gmail.com> wrote: > >>>> > >>>> Sorry for the slow response. > >>>> > >>>> My code is in C#. I don't know if the amalgamation source code in C > >>>> can be compiled so it is compatible with C#. > >>>> > >>>> If it can, I'd be interested in details. Thanks! > >>>> > >>>>> On Sat, Feb 18, 2017 at 1:29 AM, R Smith <rsm...@rsweb.co.za> wrote: > >>>>> > >>>>> > >>>>>>> On 2017/02/18 12:45 AM, Warren Young wrote: > >>>>>>> > >>>>>>> On Feb 17, 2017, at 7:32 AM, R Smith <rsm...@rsweb.co.za> wrote: > >>>>>>> > >>>>>>> You can even checkout the latest commits via SVN > >>>>>> > >>>>>> There’s a Subversion mirror of the official Fossil code repository > for > >>>>>> SQLite? > >>>>> > >>>>> > >>>>> Apologies, force of habit nomenclature. Have fallen to calling any > Software > >>>>> Versioning system just 'SVN' for short. I did of course mean for it > to be > >>>>> checked out via Fossil. > >>>>> > >>>>>> https://goo.gl/KzLcV8 > >>>>>> > >>>>>> (Excuse the shortener, it’s a reeeealy long URL.) > >>>>>> > >>>>>> I could give you that Zip file link, but I suspect it’s purposely > not > >>>>>> being published to avoid load on the SQLite repository server > caused by bots > >>>>>> repeatedly requesting Zip files and tarballs. > >>>>> > >>>>> > >>>>> The bots can read goo links nowadays. ;) > >>>>> > >>>>>> Using Fossil is far more efficient than downloading Zip archives, > but as I > >>>>>> keep getting reminded in my own Fossil-hosted public project, some > people > >>>>>> just refuse to install and use anything they don’t absolutely have > to. It’s > >>>>>> six easy steps, but apparently that’s too many for some. > >>>>> > >>>>> > >>>>> Agreed, and what is more sad is that Fossil is so much better at > actual > >>>>> "Version-Control" (as opposed to making sharing code easiest). If we > could > >>>>> get the rest of the World to rather Fossil, everybody wins. (I can > already > >>>>> hear Linus clutching his chest and breathing erratically!) > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> sqlite-users mailing list > >>>>> sqlite-users@mailinglists.sqlite.org > >>>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > >>>> _______________________________________________ > >>>> sqlite-users mailing list > >>>> sqlite-users@mailinglists.sqlite.org > >>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > >>> _______________________________________________ > >>> sqlite-users mailing list > >>> sqlite-users@mailinglists.sqlite.org > >>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > >> _______________________________________________ > >> sqlite-users mailing list > >> sqlite-users@mailinglists.sqlite.org > >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
