System.Data.SQLite
Check-in [d982172318]
Not logged in

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Add question #20 to FAQ.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1:d982172318a183fe291324a643e51aa1d1f12ec1
User & Date: mistachkin 2012-04-05 19:49:28
Context
2012-04-07
22:18
Update all versions to 1.0.81.0. Add DefineConstants property to the SQLiteConnection class to return the list of define constants used when compiling the core managed assembly. Support compiling the interop assembly without support for the custom extension functions and the CryptoAPI based codec. check-in: fd6a7e09b8 user: mistachkin tags: trunk
2012-04-05
19:49
Add question #20 to FAQ. check-in: d982172318 user: mistachkin tags: trunk
2012-04-03
03:58
Simplify the native library pre-loading code. Also, allow the selected processor architecture to be overridden via the environment variable 'PreLoadSQLite_ProcessorArchitecture'. check-in: 48466de4f9 user: mistachkin tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to www/faq.wiki.

92
93
94
95
96
97
98








99
100
101
102
103
104
105
...
440
441
442
443
444
445
446






























  </li>
  <br>
  <li>
    <a href="#q19">When the solution is loaded in Visual Studio, why do no files
    show up for several of the projects in the <b>Solution Explorer</b> window?
    </a>
  </li>








</ol>

<hr>
<a name="q1"></a>
<p>
  <b>(1) When will the next version of System.Data.SQLite be released?</b>
</p>
................................................................................
  contains the actual references to the C# source code files.  Unfortunately,
  due to limitations on how Visual Studio reads and interprets MSBuild files at
  design-time, the C# source code files do not show up in the Solution Explorer
  window.  This limitation is largely cosmetic and does <b>not</b> impact the
  correctness of the build process itself, whether in Visual Studio or when
  using MSBuild on the command line.
</p>





































>
>
>
>
>
>
>
>







 







>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
...
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
  </li>
  <br>
  <li>
    <a href="#q19">When the solution is loaded in Visual Studio, why do no files
    show up for several of the projects in the <b>Solution Explorer</b> window?
    </a>
  </li>
  <br>
  <li>
    <a href="#q20">When the System.Data.SQLite project is compiled and run from
    inside Visual Studio, why do I get a <b>DllNotFoundException</b> or a
    <b>BadImageFormatException</b> (for &quot;sqlite3.dll&quot; or
    &quot;SQLite.Interop.dll&quot;) when trying to run or debug the application?
    </a>
  </li>
</ol>

<hr>
<a name="q1"></a>
<p>
  <b>(1) When will the next version of System.Data.SQLite be released?</b>
</p>
................................................................................
  contains the actual references to the C# source code files.  Unfortunately,
  due to limitations on how Visual Studio reads and interprets MSBuild files at
  design-time, the C# source code files do not show up in the Solution Explorer
  window.  This limitation is largely cosmetic and does <b>not</b> impact the
  correctness of the build process itself, whether in Visual Studio or when
  using MSBuild on the command line.
</p>

<hr>
<a name="q20"></a>
<p>
  <b>(20) When the System.Data.SQLite project is compiled and run from inside
  Visual Studio, why do I get a DllNotFoundException or a BadImageFormatException
  (for &quot;sqlite3.dll&quot; or &quot;SQLite.Interop.dll&quot;) when trying to
  run or debug the application?</b>
</p>

<p>
  When compiling and running a solution from within Visual Studio that uses the
  System.Data.SQLite project (including the test project), it is very important
  to select the correct build configuration and platform.  First, managed
  applications to be debugged inside Visual Studio cannot use the mixed-mode
  assembly (i.e. because it is always compiled to the platform-specific build
  output directory).  This is necessary to properly support building binaries
  for multiple platforms using the same source project files.  Therefore, only
  the &quot;DebugNativeOnly&quot; or &quot;ReleaseNativeOnly&quot; build
  configurations should be selected when running a managed application from
  inside Visual Studio that relies upon the System.Data.SQLite assembly.  These
  build configurations contain a custom post-build step that copies the required
  native assembly to the managed output directory (i.e. to enable running the
  managed binaries in-place).  However, this post-build step will only be
  performed if the selected platform matches that of the operating system (e.g.
  &quot;Win32&quot; for 32-bit Windows and &quot;x64&quot; for 64-bit Windows).
  Therefore, it is good practice to double-check the selected build platform
  against the operating system prior to attempting to run a managed project in
  the solution.
</p>