SQLite Forum

The precompiled managed assemblies within the official NuGet packages are
only intended to be used with the interop assemblies also from those NuGet
packages.

I'm not sure how you were able to get a different result before; however,
everything appears to be working as designed.

Your example executes the SQL statement "PRAGMA table_info(test)".

However, the result rows returned by that SQL statement do not have
associated data type names, because those rows are not actually part
of a declared table.

Could you please include some more specifics about the nature of the issue
you are seeing?

For example, a database schema and/or snippet of C# code that demonstrates
the issue.

You should be able to take the link to a current version of the download, e.g.
1.0.115.0 and replace the version number with 1.0.111.0 to obtain that file
from the previous release.

In general, the latest release of System.Data.SQLite should be used.  There
should not be any backward incompatible changes between releases unless they
are specially marked in the release notes, e.g.:

[https://system.data.sqlite.org/index.html/doc/trunk/www/news.wiki]

If the latest release of System.Data.SQLite cannot be used, it should still
be possible to force a previous release to be used via the "package restore"
feature of NuGet:

[https://docs.microsoft.com/en-us/nuget/consume-packages/package-restore]

Are you able to manually dispose of the SQLiteDataReader and SQLiteCommand
objects associated with a connection?

If not, is there is some external code making use of those objects?

EDIT #1: Meanwhile, I'm going to add a managed event that exposes the busy
         handler.

EDIT #2: Please see [https://system.data.sqlite.org/index.html/info/2541fcec64c42a1d].

These defines are all used by various build processes, some of which are
internal.

System.Data.SQLite does not currently have support for shared cache mode;
therefore, using PRAGMA read_uncommitted will have no effect.

The root cause of this will be extremely difficult to pin down without more
details on the observed behavior, e.g. example code, example schema, stack
traces, etc.

The PreLoadSQLite_LibraryFileNameOnly setting is not designed to be used in this
way.

I think in order to accomplish what you are wanting, the existing P/Invoke layer
would have to switch to dynamically created delegates, i.e. no DllImport and no
need for a constant SQLITE_DLL.  That would be a large change in behavior, which
would risk breaking backwards compatibility.

So far, I do not see a clean way to work around this issue in MSBuild.

Given how complex (and fragile) the NuGet packaging has been, I sincerely
hesitate to add more complexity here, as it would risk breaking (correct)
versions of MSBuild and/or Visual Studio.

I think the most reliable course of action would be to remove the legacy
encryption using an older version of System.Data.SQLite and then encrypt
using SEE.

Based on this log output, it appears the "CopySQLiteInteropFiles" MSBuild
property is ending up with a value of "false".  This will disable the copy
step in the associated target.

At a minimum, I would skip setting this value to "false" in your project
files and MSBuild targets files.

It might be useful to examine the full MSBuild logs.  Can you build your project
with diagnostic logging enabled, e.g. something like:

   dotnet build the_project.csproj --verbosity diagnostic > "%TEMP\build.log"

Why is the following section present in your project file?

  <PropertyGroup>
    <ContentSQLiteInteropFiles>true</ContentSQLiteInteropFiles>
    <CopySQLiteInteropFiles>false</CopySQLiteInteropFiles>
    <CleanSQLiteInteropFiles>false</CleanSQLiteInteropFiles>
    <CollectSQLiteInteropFiles>false</CollectSQLiteInteropFiles>
  </PropertyGroup>

It should not be necessary.  Could you please try removing it?

This proposal seems a bit risky given the nesting of single quote characters.

Does MSBuild actually support this?

Perhaps a more complex MSBuild target is needed with a well-defined sequence
of assignments that do not require nesting of single quotes?

I will look into the feasibility of fixing this issue in a portable and
reliable way later this week.

The "Password" connection string property relied upon the legacy CryptoAPI
codec.  That code has been unmaintained since 2011, unsupported since 2017,
and completely non-functional since release 1.0.113.0 due to changes in the
underlying core library architecture.

If you need to continue using this feature, you'll need to continue using a
version prior to 1.0.113.0.

Thanks for the report.

I've looked at the command builder class and didn't notice anything obvious
that explains the times you are seeing; however, I would like to note that
it relies heavily upon the DbCommandBuilder class provided by .NET itself.

That being said, I'm open to suggestions on how to make it faster as long
as we can retain backwards compatibility.