search

ericsink / SQLitePCL.raw

A Portable Class Library (PCL) for low-level (raw) access to SQLite
Apache License 2.0
512 stars 106 forks source link

[BUG] SQLitePCLRaw.lib.e_sqlite3 not compatible with packages.config #492

Open plamen-i opened 2 years ago

plamen-i commented 2 years ago

Hi @ericsink

Consuming project; WPF .NET Framework 4.7.2 (old style project targeting AnyCPU) using packages.config Bug in: 2.1.0 Last good version: 2.0.7

Actually this project is host for Xamarin.Forms for WPF application and I have difficulties to switch it to PackageReference. So I decide to use it that way until eventual migration to MAUI.

Until 2.0.7 this works but now native e_sqlite3.dll isn't copied to output folder when building project. According to documentation the problem can be incompatibility with packages.config as targets file is only in buildTransition folder (for PackageReference) and is not duplicated in build folder (for packages.config).

Plamen

ericsink commented 2 years ago

I plan to investigate this, but at the moment I am not certain whether I am willing to commit to support packages.config anymore.

Stannieman commented 1 year ago

Isn't it just a matter of putting the targets file in the build folder again?

ericsink commented 1 year ago

Isn't it just a matter of putting the targets file in the build folder again?

Maybe, but probably not. Almost every change to this aspect of the project results in unintended consequences. Nothing about this area is ever as simple as it seems.

To illustrate that concept, I would simply reverse the question: "Isn't it just a matter of updating from packages.config to PackageReference?" :-)

Stannieman commented 1 year ago

Ok you got me there with that last one :D Adding the build folder back works for me but indeed I do not know what it does to PackageReference projects.

Anyway it is not critical for me, it's an app that will be EOL in a year (which is also why I won't bother moving to PackageReference in the first place) 🤷

georg-jung commented 1 year ago

Allow package authors to define build assets transitive behavior reads

To construct a package which allows build assets to flow transitively, package author will need to put all these build assets in /buildTransitive as well as /build folder to make the package compatible with packages.config.

This approach also seems to be chosen by other popular native asset distributions, e.g. SkiaSharp.

(I don't have any need for packages.config support. Just stumbled upon this issue and thought adding that info might not hurt.)