Update to SQLitePCLRaw 3.x

[ericsink]

See #36535

This PR updates the package reference for SQLitePCLRaw to 3.0.1.

The most significant aspect of this change: Because the e_sqlcipher and e_sqlite3mc bundles have been deprecated, I have removed the corresponding test programs from EFCore.sln. However, their respective csproj files are still present.

[AndriySvyryd]

I discussed this with the team and we think that at this point it's too risky to do this for 10, instead we could do it early for 11 (next week) so we have time to gather feedback and prepare upgrade documentation.

[ericsink]

Acknowledged. Thanks for the update.

[cincuranet]

@ericsink On Linux it is failing with /home/vsts/work/1/s/.dotnet/sdk/10.0.100-rc.1.25411.109/Microsoft.Common.CurrentVersion.targets(5381,5): error MSB3030: Could not copy the file "/home/vsts/work/1/s/.packages/sourcegear.sqlite3/3.50.3/runtimes/linux-riscv64/native/libe_sqlite3.so" because it was not found. [/home/vsts/work/1/s/test/Microsoft.Data.Sqlite.Tests/Microsoft.Data.Sqlite.Tests.csproj::TargetFramework=net481] (link).

[ericsink]

I will investigate. Thanks for highlighting the error.

[ericsink]

I see the problem with my package, but I'm not quite seeing how it would happen, and I want to make sure I'm not missing something.

The test suite must be running on (or building for) a number of different Linux configurations, and linux-riscv64 is apparently one of them. Is that list of configurations or RIDs in the repo somewhere so I can verify any others that might cause problems?

[cincuranet]

As far as I'm aware, we're building only for linux-x64.

[ericsink]

Hmmm. Then the error message is a bit of a mystery then. I'll dig more. Thanks.

[ericsink]

I found the problem. My mistake. Fix pending.

[ericsink]

I'm taking the opportunity to fix some other problems with the targets file. I should be updating this PR next week.

[AndriySvyryd]

Now it's failing with

.packages\sourcegear.sqlite3\3.50.4.2\buildTransitive\net471\SourceGear.sqlite3.props(6,9): error : This package does not support Any CPU builds [D:\a_work\1\s\test\Microsoft.Data.Sqlite.Tests\Microsoft.Data.Sqlite.Tests.csproj::TargetFramework=net481]

[ericsink]

Thanks. I'll take a look.

[ericsink]

I've pushed up a build fix, but I'd like to highlight the most recent commit as something that might need further review and discussion.

In a nutshell, SQLitePCLRaw 3.0 does not support "Any CPU" builds, and there is a new error build-time error message intended to make that clear. The change I just committed works around the problem with Microsoft.Data.Sqlite.Tests by setting a RuntimeIdentifer in that csproj when the target framework is .NET Framework.

[bairog]

In a nutshell, SQLitePCLRaw 3.0 does not support "Any CPU" builds

@ericsink Could you clarify: Any CPU builds are not supported by the moment and will be fixed later or they will not be supported at all? If latter - how to have a .NFW472 application that can run both on x86 and x64 Windows?

[ericsink]

When I said that the current packages do not support "Any CPU", what I specifically mean is that they currently do not have the ability to build one non-CPU-specific managed assembly, and then bundle one unmanaged DLL for each CPU architecture, and then dynamically, at runtime, load the appropriate unmanaged DLL depending on the current CPU architecture. However, building one separate configuration for each CPU should work fine, including x64, x86, and arm64. I am investigating the possibility of adding an "Any CPU" feature, but I do not know if or when it would be available.

[bairog]

@ericsink Hmm, in my test .net472 application I still get BadImageFormatException even if I add <RuntimeIdentifer>win-x64</RuntimeIdentifer> to .csproj. Only adding <PlatformTarget>x64</PlatformTarget> helps. But with it I cannot have a build that can run both on x86 and x64 Windows (RuntimeIdentifer can be multiple, but PlatformTarget cannot). My sample repo.

[ericsink]

(I am following up on the previous comment in another forum where it was also posted)