Re: SQLite.Interop.dll

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SQLite.Interop.dll

Clyde Eisenbeis
-------------------
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\x86
... and under ... \x64.

Is there a better place to put SQLite.Interop.dll so it works?
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SQLite.Interop.dll

Barry Smith
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 <[hidden email]> 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\x86
> ... and under ... \x64.
>
> Is there a better place to put SQLite.Interop.dll so it works?
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SQLite.Interop.dll

Lee Gray
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:[hidden email]] On Behalf Of Barry Smith
Sent: Thursday, February 23, 2017 12:53 PM
To: SQLite mailing list <[hidden email]>
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 <[hidden email]> 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
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SQLite.Interop.dll

Clyde Eisenbeis
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 <[hidden email]> 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:[hidden email]] On Behalf Of Barry Smith
> Sent: Thursday, February 23, 2017 12:53 PM
> To: SQLite mailing list <[hidden email]>
> 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 <[hidden email]> 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
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SQLite.Interop.dll

Lee Gray
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:[hidden email]] On Behalf Of Clyde Eisenbeis
Sent: Friday, February 24, 2017 11:03 AM
To: SQLite mailing list <[hidden email]>
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 <[hidden email]> 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:[hidden email]] On Behalf Of
> Barry Smith
> Sent: Thursday, February 23, 2017 12:53 PM
> To: SQLite mailing list <[hidden email]>
> 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 <[hidden email]> 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
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SQLite.Interop.dll

Clyde Eisenbeis
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 <[hidden email]> 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:[hidden email]] On Behalf Of Clyde Eisenbeis
> Sent: Friday, February 24, 2017 11:03 AM
> To: SQLite mailing list <[hidden email]>
> 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 <[hidden email]> 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:[hidden email]] On Behalf Of
>> Barry Smith
>> Sent: Thursday, February 23, 2017 12:53 PM
>> To: SQLite mailing list <[hidden email]>
>> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>> _______________________________________________
>> sqlite-users mailing list
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>> _______________________________________________
>> sqlite-users mailing list
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SQLite.Interop.dll

Lee Gray
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:[hidden email]] On Behalf Of Clyde Eisenbeis
Sent: Friday, February 24, 2017 12:54 PM
To: SQLite mailing list <[hidden email]>
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 <[hidden email]> 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:[hidden email]] On Behalf Of
> Clyde Eisenbeis
> Sent: Friday, February 24, 2017 11:03 AM
> To: SQLite mailing list <[hidden email]>
> 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 <[hidden email]> 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:[hidden email]] On Behalf Of
>> Barry Smith
>> Sent: Thursday, February 23, 2017 12:53 PM
>> To: SQLite mailing list <[hidden email]>
>> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>> _______________________________________________
>> sqlite-users mailing list
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>> _______________________________________________
>> sqlite-users mailing list
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Loading...