Lee, I have an .sln file that is in a folder (there is no .csproj or .vbproj file). Inside that folder are additional folders -> eventually drills down to bin\Debug.
"Right-click your solution" ... do you mean inside VS (Visual Studio 2013)? When I right-click inside VS, my only choice is "new solution explorer view". On Fri, Feb 24, 2017 at 12:11 PM, Lee Gray <[email protected]> wrote: > 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 _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
