System.Data.SQLite Deployment Mystery

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
pdb
Reply | Threaded
Open this post in threaded view
|

System.Data.SQLite Deployment Mystery

pdb
I'm wondering if there is a bug somehow in the "System.Data.SQLite" dll
file.  

 

When deploying my application to a clean Windows 7 x64 virtual machine
(VMWare Workstation 10), I got the message "Failed to find or load the
registered .NET Framework Data Provider" and of course with no database the
app would crash.  I then installed the file:
"sqlite-netFx45-setup-bundle-x86-2012-1.0.88.0.exe" (retrieved from your web
site) to this clean machine. I did NOT install it to the GAC which of course
also eliminated the Visual Studio Design stuff. At that point, I ran my app
again and it worked as expected.  I then went into the control panel and
uninstalled "System.Data.SQLite" and then tried running the application
again and it worked.  Quite a mystery there.

 

Seems like there is something that the
"sqlite-netFx45-setup-bundle-x86-2012-1.0.88.0.exe" installation file is
installing on the machine that is required for the database to be
recognized.  The application has the correct SQLite dll files which matched
the ones installed by the "System.Data.SQLite" installation file, so it's
not a missing dll, at least it's not missing "System.Data.SQLite.dll" or
"System.Data.SQLite.Linq.dll" as those are both put into the bin\debug
directory from the Visual Studio project.

 

I really enjoy working with the SQLite database, but I need it to work
without having to run the "System.Data.SQLite" installation.  I know that's
a mute-point because I don't believe that is what you guys intended either.
It's a pretty simple scenario, so hopefully I've given enough information to
help diagnose what is going on. If there is any other information that would
be helpful, please let me know.  Thank you very much for your help on this
issue.

 

Sincerely,

Paul Bainter

 

_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: System.Data.SQLite Deployment Mystery

Joe Mistachkin-3

Paul Bainter wrote:
>
> When deploying my application to a clean Windows 7 x64 virtual machine
> (VMWare Workstation 10), I got the message "Failed to find or load the
> registered .NET Framework Data Provider" and of course with no database
> the app would crash.  
>

When does this error appear?  What application is raising it?

The .NET Framework Data Provider configuration is normally found within
the "app.config" file (i.e. "App locally") or the machine-wide configuration
file.  The "app.config" file needs to be present in the directory containing
the primary executable managed file for the application and must be named
"${exeFileName}.config", where "${exeFileName}" is the name of the
executable.

Example:

        test.exe -- Executable file name.
        test.exe.config -- The "app.config" file name.

>
> I then installed the file:
> "sqlite-netFx45-setup-bundle-x86-2012-1.0.88.0.exe" (retrieved from your
web
> site) to this clean machine. I did NOT install it to the GAC which of
course
> also eliminated the Visual Studio Design stuff. At that point, I ran my
app
> again and it worked as expected.  
>

The setup bundle modifies the machine-wide configuration file to add the
SQLite ADO.NET provider.  However, when deploying to any machine that does
not
require the Visual Studio design-time functionality, add the necessary
section
to the "app.config" file is recommended instead.  The file should look
something
like this:

<configuration>
  <system.data>
    <DbProviderFactories>
      <remove invariant="System.Data.SQLite" />
      <add name="SQLite Data Provider" invariant="System.Data.SQLite"
description=".Net Framework Data Provider for SQLite"
type="System.Data.SQLite.SQLiteFactory, System.Data.SQLite,
Version=1.0.88.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139" />
    </DbProviderFactories>
  </system.data>
</configuration>

--
Joe Mistachkin

_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: System.Data.SQLite Deployment Mystery

dpybus
In reply to this post by pdb
I have an identical problem. I cannot deploy an app which uses either Net 4.5 or 4.5.1 with the appropriate sqlite dll. It can be fixed by installing the sqlite package on the target computer.
Reply | Threaded
Open this post in threaded view
|

Re: System.Data.SQLite Deployment Mystery

Joe Mistachkin-3

dpybus wrote:
>
> I have an identical problem. I cannot deploy an app which uses either Net
4.5
> or 4.5.1 with the appropriate sqlite dll. It can be fixed by installing
the
> sqlite package on the target computer.
>

Generally, there are three types of issues with System.Data.SQLite
deployment:

1.  Attempting to use the native interop assembly (or native library)
without
    the necessary Microsoft Visual C++ Runtime Libraries installed.

2.  Attempting to use the 32-bit native interop assembly (or native library)
    in a 64-bit process or vice-versa.

3.  Loading the managed-only System.Data.SQLite assembly in such a way that
it
    cannot locate its associated native interop assembly (or native
library).
    With the introduction [and refinement] of the "native library
pre-loading"
    feature, this frequency of this issue has declined significantly.  One
way
    to see this type of issue is to install the managed-only
System.Data.SQLite
    assembly in the GAC without making the associated native interop
assembly
    available somewhere in the PATH.

In this case, I suspect the problem is #1.  Running the free Dependency
Walker
tool (from http://dependencywalker.com/ ) against the native interop
assembly
("SQLite.Interop.dll") on the target machine should reveal if that is the
case.

If that does turn out to be the case, it can normally be solved by
installing
one of the packages from:

        https://support.microsoft.com/kb/2019667

--
Joe Mistachkin

_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: System.Data.SQLite Deployment Mystery

Incongruous
Oh boy! This sounds like another good reason to stay with C++.
.Net is becoming more and more problematic as I explore it.
-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Joe Mistachkin
Sent: Monday, March 17, 2014 12:34 AM
To: 'General Discussion of SQLite Database'
Subject: Re: [sqlite] System.Data.SQLite Deployment Mystery


dpybus wrote:
>
> I have an identical problem. I cannot deploy an app which uses either
> Net
4.5
> or 4.5.1 with the appropriate sqlite dll. It can be fixed by
> installing
the
> sqlite package on the target computer.
>

Generally, there are three types of issues with System.Data.SQLite
deployment:

1.  Attempting to use the native interop assembly (or native library)
without
    the necessary Microsoft Visual C++ Runtime Libraries installed.

2.  Attempting to use the 32-bit native interop assembly (or native library)
    in a 64-bit process or vice-versa.

3.  Loading the managed-only System.Data.SQLite assembly in such a way that
it
    cannot locate its associated native interop assembly (or native
library).
    With the introduction [and refinement] of the "native library
pre-loading"
    feature, this frequency of this issue has declined significantly.  One
way
    to see this type of issue is to install the managed-only
System.Data.SQLite
    assembly in the GAC without making the associated native interop
assembly
    available somewhere in the PATH.

In this case, I suspect the problem is #1.  Running the free Dependency
Walker tool (from http://dependencywalker.com/ ) against the native interop
assembly
("SQLite.Interop.dll") on the target machine should reveal if that is the
case.

If that does turn out to be the case, it can normally be solved by
installing one of the packages from:

        https://support.microsoft.com/kb/2019667

--
Joe Mistachkin

_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: System.Data.SQLite Deployment Mystery

Markus Schaber
In reply to this post by Joe Mistachkin-3
Hi,

Von: [hidden email] [mailto:[hidden email]]

>
> dpybus wrote:
> >
> > I have an identical problem. I cannot deploy an app which uses either
> > Net
> 4.5
> > or 4.5.1 with the appropriate sqlite dll. It can be fixed by
> > installing
> the
> > sqlite package on the target computer.
> >
>
> Generally, there are three types of issues with System.Data.SQLite
> deployment:
>
> 1.  Attempting to use the native interop assembly (or native library) without
>     the necessary Microsoft Visual C++ Runtime Libraries installed.
>
> 2.  Attempting to use the 32-bit native interop assembly (or native library)
>     in a 64-bit process or vice-versa.
>
> 3.  Loading the managed-only System.Data.SQLite assembly in such a way that it
>     cannot locate its associated native interop assembly (or native library).
>     With the introduction [and refinement] of the "native library pre-loading"
>     feature, this frequency of this issue has declined significantly. One way
>     to see this type of issue is to install the managed-only System.Data.SQLite
>     assembly in the GAC without making the associated native interop assembly
>     available somewhere in the PATH.

SharpSVN (https://sharpsvn.open.collab.net/) uses some build trickery to link
native libraries in a way that they're kept as "external resource files" along
with the assembly. This means that VS and MSBuild copy them along with the main
assembly, and it is also installed into the GAC along with the main assembly.

The trick seems to be the <AssemblyLinkResource> tag below in the vcxproj file:

    <Link>
      <AdditionalDependencies>Advapi32.lib;shell32.lib;Rpcrt4.lib;Mswsock.lib;Crypt32.lib;User32.lib</AdditionalDependencies>
      <AdditionalLibraryDirectories>..\..\imports\release\lib;..\..\imports\release\lib-AnyCPU;..\..\imports\release\bin;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
      <DelayLoadDLLs>SharpSvn-DB44-20-$(Platform).svnDll;crypt32.dll;mswsock.dll;secur32.dll;user32.dll;ole32.dll;advapi32.dll;%(DelayLoadDLLs)</DelayLoadDLLs>
      <AssemblyLinkResource>$(TargetDir)SharpSvn-DB44-20-$(Platform).svnDll;$(TargetDir)SharpPlink-$(Platform).svnExe;%(AssemblyLinkResource)</AssemblyLinkResource>
      <GenerateDebugInformation>true</GenerateDebugInformation>
      <AssemblyDebug>true</AssemblyDebug>
      <TargetMachine>MachineX86</TargetMachine>
      <KeyFile>SharpSvn.snk</KeyFile>
      <LinkTimeCodeGeneration>UseLinkTimeCodeGeneration</LinkTimeCodeGeneration>
      <ImageHasSafeExceptionHandlers>true</ImageHasSafeExceptionHandlers>
    </Link>

It links both a DLL and an exe file that way. (The file endings are changed to reduce confusion of other software.)

When installing into the GAC, they both are copied along into the same directory as the SharpSVN Assembly itsself, where they can be found and loaded / executed.

Maybe this trick could be used by System.Data.SQLlite as well - however, I'm currently not sure whether it is possible to create such linkage with C#, maybe some postprocessing is necessary.

On the other hand, SharpSVN also links a lot of native code directly into the DLL - using C++/CLI instead of C#, this is rather easy.

Best regards

Markus Schaber

CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: [hidden email] | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

RE: System.Data.SQLite Deployment Mystery

dpybus

Dear Markus,

 

Thank you for your helpful comments. I’ve finally got it going on ‘naïve’ Win 8 (and Win 7) computers, but I don’t understand why!!

 

In short, I got it going by adopting the technique described here:

 

http://rashimuddin.wordpress.com/tag/sqlite-interop-dll/

 

Perhaps you can suggest why this has worked?

 

Yours Sincerely,

 

Andy Pybus

 

 

From: Markus Schaber [via SQLite] [mailto:[hidden email]]
Sent: Monday, 17 March 2014 9:55 PM
To: dpybus
Subject: Re: System.Data.SQLite Deployment Mystery

 

Hi,

Von: [hidden email] [mailto:[hidden email]]


>
> dpybus wrote:
> >
> > I have an identical problem. I cannot deploy an app which uses either
> > Net
> 4.5
> > or 4.5.1 with the appropriate sqlite dll. It can be fixed by
> > installing
> the
> > sqlite package on the target computer.
> >
>
> Generally, there are three types of issues with System.Data.SQLite
> deployment:
>
> 1.  Attempting to use the native interop assembly (or native library) without
>     the necessary Microsoft Visual C++ Runtime Libraries installed.
>
> 2.  Attempting to use the 32-bit native interop assembly (or native library)
>     in a 64-bit process or vice-versa.
>
> 3.  Loading the managed-only System.Data.SQLite assembly in such a way that it
>     cannot locate its associated native interop assembly (or native library).
>     With the introduction [and refinement] of the "native library pre-loading"
>     feature, this frequency of this issue has declined significantly. One way
>     to see this type of issue is to install the managed-only System.Data.SQLite
>     assembly in the GAC without making the associated native interop assembly
>     available somewhere in the PATH.

SharpSVN (https://sharpsvn.open.collab.net/) uses some build trickery to link
native libraries in a way that they're kept as "external resource files" along
with the assembly. This means that VS and MSBuild copy them along with the main
assembly, and it is also installed into the GAC along with the main assembly.

The trick seems to be the <AssemblyLinkResource> tag below in the vcxproj file:

    <Link>
      <AdditionalDependencies>Advapi32.lib;shell32.lib;Rpcrt4.lib;Mswsock.lib;Crypt32.lib;User32.lib</AdditionalDependencies>
      <AdditionalLibraryDirectories>..\..\imports\release\lib;..\..\imports\release\lib-AnyCPU;..\..\imports\release\bin;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
      <DelayLoadDLLs>SharpSvn-DB44-20-$(Platform).svnDll;crypt32.dll;mswsock.dll;secur32.dll;user32.dll;ole32.dll;advapi32.dll;%(DelayLoadDLLs)</DelayLoadDLLs>
      <AssemblyLinkResource>$(TargetDir)SharpSvn-DB44-20-$(Platform).svnDll;$(TargetDir)SharpPlink-$(Platform).svnExe;%(AssemblyLinkResource)</AssemblyLinkResource>
      <GenerateDebugInformation>true</GenerateDebugInformation>
      <AssemblyDebug>true</AssemblyDebug>
      <TargetMachine>MachineX86</TargetMachine>
      <KeyFile>SharpSvn.snk</KeyFile>
      <LinkTimeCodeGeneration>UseLinkTimeCodeGeneration</LinkTimeCodeGeneration>
      <ImageHasSafeExceptionHandlers>true</ImageHasSafeExceptionHandlers>
    </Link>

It links both a DLL and an exe file that way. (The file endings are changed to reduce confusion of other software.)

When installing into the GAC, they both are copied along into the same directory as the SharpSVN Assembly itsself, where they can be found and loaded / executed.

Maybe this trick could be used by System.Data.SQLlite as well - however, I'm currently not sure whether it is possible to create such linkage with C#, maybe some postprocessing is necessary.

On the other hand, SharpSVN also links a lot of native code directly into the DLL - using C++/CLI instead of C#, this is rather easy.

Best regards

Markus Schaber

CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: [hidden email] | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


If you reply to this email, your message will be added to the discussion below:

http://sqlite.1065341.n5.nabble.com/System-Data-SQLite-Deployment-Mystery-tp71752p74581.html

To unsubscribe from System.Data.SQLite Deployment Mystery, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

RE: System.Data.SQLite Deployment Mystery

dpybus
In reply to this post by Joe Mistachkin-3

Dear Joe,

 

Thank you for your helpful comments. I’ve finally got it going on ‘naïve’ Win 8 (and Win 7) computers, but I don’t understand why!!

 

In short, I got it going by adopting the technique described here:

 

http://rashimuddin.wordpress.com/tag/sqlite-interop-dll/

 

Perhaps you can suggest why this has worked?

 

Yours Sincerely,

 

Andy Pybus

 

 

From: Joe Mistachkin-3 [via SQLite] [mailto:[hidden email]]
Sent: Monday, 17 March 2014 3:35 PM
To: dpybus
Subject: Re: System.Data.SQLite Deployment Mystery

 


dpybus wrote:
>
> I have an identical problem. I cannot deploy an app which uses either Net
4.5
> or 4.5.1 with the appropriate sqlite dll. It can be fixed by installing
the
> sqlite package on the target computer.
>

Generally, there are three types of issues with System.Data.SQLite
deployment:

1.  Attempting to use the native interop assembly (or native library)
without
    the necessary Microsoft Visual C++ Runtime Libraries installed.

2.  Attempting to use the 32-bit native interop assembly (or native library)
    in a 64-bit process or vice-versa.

3.  Loading the managed-only System.Data.SQLite assembly in such a way that
it
    cannot locate its associated native interop assembly (or native
library).
    With the introduction [and refinement] of the "native library
pre-loading"
    feature, this frequency of this issue has declined significantly.  One
way
    to see this type of issue is to install the managed-only
System.Data.SQLite
    assembly in the GAC without making the associated native interop
assembly
    available somewhere in the PATH.

In this case, I suspect the problem is #1.  Running the free Dependency
Walker
tool (from http://dependencywalker.com/ ) against the native interop
assembly
("SQLite.Interop.dll") on the target machine should reveal if that is the
case.

If that does turn out to be the case, it can normally be solved by
installing
one of the packages from:

        https://support.microsoft.com/kb/2019667

--
Joe Mistachkin

_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


If you reply to this email, your message will be added to the discussion below:

http://sqlite.1065341.n5.nabble.com/System-Data-SQLite-Deployment-Mystery-tp71752p74574.html

To unsubscribe from System.Data.SQLite Deployment Mystery, click here.
NAML