in my SQLite.dll library program.
On Tue, Feb 21, 2017 at 2:42 PM, Clyde Eisenbeis <[email protected]> wrote: > I don't recall how I obtained the SQLite files ... was two years ago. > > When I have SQLite installed on my genealogy program and on my SQLite > .dll library, it works fine. > > When I don't have SQLite installed on my genealogy program, I get an > exception "Unable to load DLL 'SQLite.Interop.dll': ... " with > > sqliteConn = new System.Data.SQLite.SQLiteConnection("Data Source=" > + stPathFilename + ";"). > > On Tue, Feb 21, 2017 at 12:26 PM, Barry <[email protected]> wrote: >> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> wrote: >>> >>>>> >>> >>>>> >>> >>>>>>> On 2017/02/18 12:45 AM, Warren Young wrote: >>> >>>>>>> >>> >>>>>>> On Feb 17, 2017, at 7:32 AM, R Smith <[email protected]> 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 >>> >>>>> [email protected] >>> >>>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >>> >>>> _______________________________________________ >>> >>>> sqlite-users mailing list >>> >>>> [email protected] >>> >>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >>> >>> _______________________________________________ >>> >>> sqlite-users mailing list >>> >>> [email protected] >>> >>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >>> >> _______________________________________________ >>> >> sqlite-users mailing list >>> >> [email protected] >>> >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >>> > _______________________________________________ >>> > sqlite-users mailing list >>> > [email protected] >>> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >>> _______________________________________________ >>> sqlite-users mailing list >>> [email protected] >>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >>> >> _______________________________________________ >> sqlite-users mailing list >> [email protected] >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
