Yeah, the interop.dll won't let you add it as a reference.
What I meant below is that you have to create the actual folder structure (<my
solution folder>\Library\x64 etc), but to add that folder to a solution (the
.sln file as opposed to a project, the .csproj or .vbproj file), you have to
duplicate the structure in the solution, since solutions do not contain
physical disk folders, just "containers". Right-click on your solution, then
click Add, then New Solution Folder. Name it the same as the physical folder
("Library"). Then create the two solution folders for x64 and x86 under that.
Finally, right-click the x64 folder, then Add, then Existing Item. Browse to
the file Library\x64\SQLite.Interop.dll. Repeat for x86. Technically, you don't
have to reproduce the folder structure in the solution. You can add the files
at the top level, and Visual Studio just automatically lumps them into a
"Solution Items" solution folder. I like to reproduce what's actually on disk.
At the project level, create the x64 and x86 project folders (which will also
create real folders on your disk, unlike at the solution level). Then right
click the folder, then Add, then Existing Item. Browse to the dll. Don't click
the Add button, though. Click the drop-down arrow, then Add As Link. That
creates a project-level link to the physical file, without copying it to the
project level folder. Right-click each file link, then click Properties. Set
the Build Action to Content, and set Copy to Output Directory to Copy if newer.
To answer your last question (should you reference from WPF or from Custom
dll), that depends on what your code accesses. In my case, I have a Windows
Forms app which does *not* directly access System.Data.SQLite, but it does
reference a class library project which references SQLite. In the class library
project, I do *not* have the project level x64/x86 folders with the interop
files added as links, but I *do* have a reference to System.Data.SQLite.dll.
The Windows Forms app has the project level x64/x86 folders with the interop
files added as links so that they get added to the *.exe's* bin folder at build
time.
If your library dll is intended to be shared among other applications, you'll
still need to provide a mechanism to get the interop files into the compiled
.exe's folder by reproducing those project folders with linked files as above,
or as previously mentioned by another poster, in other ways such as Build
Events or editing the project file's XML, etc. I did it my way so that all of
the required files could be seen at a glance in the solution/project structure.
-----Original Message-----
From: sqlite-users [mailto:[email protected]] On
Behalf Of Clyde Eisenbeis
Sent: Friday, February 24, 2017 11:03 AM
To: SQLite mailing list <[email protected]>
Subject: Re: [sqlite] SQLite.Interop.dll
Barry, I have tried adding SQLite.Interop.dll as a Reference -> error message
"SQLite.Interop.dll could not be added ...."
Lee, What is the procedure to reference a "Solution-level Library folder"?
Also, would it be referenced by my genealogy WPF or my Custom Control Library
dll?
On Fri, Feb 24, 2017 at 9:27 AM, Lee Gray <[email protected]> wrote:
> I never could get the NuGet package to cooperate with the interop dlls, so
> here's what I've done. I create a Solution-level Library folder (and matching
> physical folder) with this layout:
>
> <solution>
> \Library
> System.Data.SQLite.dll
> \x64
> SQLite.Interop.dll
> \x86
> SQLite.Interop.dll
> <project 1>
> ...
> <project n>
>
> I then reference System.Data.SQLite.dll in each project as needed, directly
> from Library. In any project that references it, I add project-level x64 and
> x86 folders. I then add the each interop file, but as a *Link* to the
> physical file under Library. I set those interop files' Build Action to
> Content, and Copy if newer. That copies the interop files, under their x64
> and x86 directories, to the correct project output directories.
>
> The initial setup is a minor pain, but after that, it just works.
>
> To get the necessary files any time there is an upgrade, I create a temp
> project and install the NuGet System.Data.SQLite.Core package, then just copy
> the appropriate 3 files to that structure above.
>
> -----Original Message-----
> From: sqlite-users
> [mailto:[email protected]] On Behalf Of
> Barry Smith
> Sent: Thursday, February 23, 2017 12:53 PM
> To: SQLite mailing list <[email protected]>
> Subject: Re: [sqlite] SQLite.Interop.dll
>
> Oh, I do remember having this issue before.
>
> I think the cause is this: Visual studio attempts to trace which dlls are
> required for each project. Then if project A is dependent on project B,
> visual studio will copy what it thinks is all the required dlls for both
> projects into project A's output directory.
>
> Unfortunately visual studio is only so smart and doesn't realise that the
> SQLite.interop.dll is a required dependency. I believe the NuGet package puts
> instructions to move those dlls to the output directory by means of xcopy.
> So, you have this situation:
>
> Project GlobalSQLite, with reference to SQLite.
> Project GeneologyControls, with reference to GlobalSQLite.
>
> Tell visual studio to build and it goes and executes the step where the
> SQLite interop DLL is copied to the output of the GlobalSQLite project. But
> then it builds GeneologyControls and doesn't realise it needs to copy the
> interop DLLs! So finally your program executes in the output directory of the
> GeneologyControls project, but the SQLite.interop.dll files are in the output
> of the other project.
>
> You need to ensure that the SQLite interop dlls are in the final output
> directory (and also included when you distribute your application). You can
> do this manually using windows explorer, or you can put in a pre or post
> build event of your final project to copy the x64 and x86 folders (containing
> the SQLite.interop.dll files) into its output directory. Doing it from
> Windows explorer is easier, but you may forget then if you do a clean build a
> few years down the line you'll run into the problem again.
>
> Perhaps there's a cleaner way to do this. Those were my solutions, though...
>
>> On 23 Feb 2017, at 1:58 PM, Clyde Eisenbeis <[email protected]> wrote:
>>
>> -------------------
>> About two years ago, I downloaded and installed SQLite. I don't
>> recall the details, but it was a program that installed SQLite.
>>
>> I ended up with files such as EntityFramework.dll,
>> EntityFramework.SqlServer.dll, System.Data.SQLite.dll, etc. This
>> required "using System.Data.SQLite".
>>
>> -------------------
>> I then created a WPF C# genealogy program ... and a GlobalSQLite.dll
>> library (as a WPF Custom Control Library).
>>
>> The GlobalSQLite.dll library contains commonly used functions. For example:
>>
>> boCreateFileAndTables(string stPathFilename,
>> List<string> liststTableNames,
>> List<string> liststFieldDefinitions)
>> {...}
>>
>> -------------------
>> I am working to improve / clean up the original code for WPF C#
>> genealogy program.
>>
>> When I have SQLite installed on my genealogy program and on my
>> GlobalSQLite.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'". It occurs in my
>> GlobalSQLite.dll library program:
>>
>> sqliteConn = new System.Data.SQLite.SQLiteConnection("Data
>> Source=" + stPathFilename + ";").
>>
>> I do find SQLite.Interop.dll under ...
>> GlobalsSQLite\packages\System.Data.SQLite.Core.1.0.101.0\build\net46\
>> x
>> 86
>> ... and under ... \x64.
>>
>> Is there a better place to put SQLite.Interop.dll so it works?
>> _______________________________________________
>> 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
