Open the Visual Studio View menu, Solution Explorer. At the very top of the
hierarchy in the Solution Explorer window, you'll see:
Solution 'ClydesSolutionName'
Right-click on that to create solution "folders".
Now... I'll try to explain again, with a visual structure.
The Visual Studio project folder structure on disk is usually:
SolutionFolderName
SolutionFileName.sln
WpfAppProjectName
WpfAppProjectName.csproj
ClassFileName.cs
ClassLibraryProjectName
ClassLibraryProjectName.vbproj
ClassFileName.vb
After building, you need System.Data.SQLite.dll and the two interop files to
end up in the same folder containing WpfAppProjectName.exe:
SolutionFolderName\WpfAppProjectName\bin\Release
System.Data.SQLite.dll will get there automatically because you've referenced
it in your class library project (ClassLibraryProjectName above). The interop
files need help.
In the structure above, I add a Library folder for 3rd party dlls under
SolutionFolderName, with the idea that multiple projects in the solution may
need references to those dlls. Using my previous instructions, I create
*solution* folders that mimic the disk folder structure. This step is not
necessary, but is for my visual satisfaction. Solution folders are just
containers in the .sln file - creating a solution folder does not automatically
create a disk folder, and vice versa.
It doesn't really matter where the files originate, as long as they end up in
the folder containing the exe file. However, this method makes sure that , if
you use source control or if you copy your solution folder somewhere else for
backup, that all the files will stay together and be part of the entire Visual
Studio solution.
-----Original Message-----
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On
Behalf Of Clyde Eisenbeis
Sent: Friday, February 24, 2017 12:54 PM
To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org>
Subject: Re: [sqlite] SQLite.Interop.dll
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 <lee.g...@morrisdickson.com> 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:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of
> Clyde Eisenbeis
> Sent: Friday, February 24, 2017 11:03 AM
> To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org>
> 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 <lee.g...@morrisdickson.com> 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:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of
>> Barry Smith
>> Sent: Thursday, February 23, 2017 12:53 PM
>> To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org>
>> 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 <cte...@gmail.com> 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
>>> 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
