Fix ios packages after device/simulator split

[filipnavara]

Tested scenarios:

• Building and running with e_sqlite3 on .NET 7 for iOS Simulator
• Building and running with e_sqlite3 on legacy Xamarin.iOS for iOS Simulator
• Building with e_sqlite3 for iOS Device with .NET 7

Not tested:

• Running on device
• e_sqlcipher

On unrelated note, we should also fix tvOS builds in the same way once we tackle the iOS ones.

[ericsink]

My changes last night were half-baked and this morning I was trying to fix them.

So NativeReference is supposed to work on legacy Xamarin? I wasn't sure about that, so I had tried to leave the embedded resource approach in place for that case.

[filipnavara]

So NativeReference is supposed to work on legacy Xamarin?

Yes. It definitely works.

The only limit of that approach is that the MSBuild scripts in build/buildTransitive are only supported from NuGet 5+. Realistically that means Visual Studio 2019+, and nothing older is supported on macOS anyway.

[ericsink]

And the testing you did -- I'm guessing you were not using one of the bundles like bundle_e_sqlite3?

The assembly for lib.e_sqlite3.ios should no longer be needed, but the bundle code and packaging still assumes it is there. I need to adjust some stuff there too.

[filipnavara]

And the testing you did -- I'm guessing you were not using one of the bundles like bundle_e_sqlite3?

Nope. Here are my test apps: iostestapps.zip

Essentially, for .NET 7 it's dotnet new ios template with nuget.config (to point to my local builds) and this:

    <PackageReference Include="SQLitePCLRaw.core" Version="2.1.4" />
    <PackageReference Include="SQLitePCLRaw.lib.e_sqlite3.ios" Version="2.1.5-pre20230515124719" />
    <PackageReference Include="SQLitePCLRaw.provider.internal" Version="2.1.4" />

and

SQLitePCL.raw.SetProvider(new SQLitePCL.SQLite3Provider_internal());
...
SQLitePCL.raw.sqlite3_libversion().utf8_to_string()

The legacy one is made from a VS template in a similar manner.

[filipnavara]

The assembly for lib.e_sqlite3.ios should no longer be needed

If you mean the .dll file then yes, it is unnecessary. It also gets stripped by the linker for device builds, so it may not be a big concern.

[ericsink]

It also gets stripped by the linker for device builds, so it may not be a big concern.

The bundle packages contain stuff to prevent the linker from stripping it out. That's what src/common/embedded_init.cs is for. It gets called from the bundle initialization code in src/common/batteries_v2.cs.

I need to rip all that out. But when I tried that last night, something went haywire with the package dependencies, because I'm using dotnet pack with stuff in the csproj for that particular package, so I may need to redo that with a regular nuspec.

It's funny how the simple addition of support for ios arm64 simulator is spidering out all over the place.