Is the lib\Xamarin.iOS10 missing in the latest 0.8.0.0 version on purpose?

[PureWeen]

I'm guessing I'm just not seeing a readme somewhere about this change and how to make it work

I'm using Akavache from @paulcbetts and noticed that my project stopped running on ios complaining that it couldn't find SQLitePCL.raw version 0.6.1.0...

Project runs fine on Android and Windows

I noticed for the nuget package the lib\Xamarin.iOS10 folder is empty for version 0.8.0.0 so I downgraded the project to 0.7.1.0 (because it's not empty in that version) and now it's all running without any issues

Am I missing something about how to make version 0.8 work?

[ericsink]

In 0.8.0, that DLL moved from the lib dir to the build dir tree, and its inclusion in the project is controlled by an msbuild targets file.

But all that should be working. Can you say more about your situation so we can figure out what's different?

[PureWeen]

Aw there it is it's in the build folder... Kind of sad I didn't see that

So the issue I ran into is that I have Akavache installed through nuget and everything has been working fine in iOS... I upgraded the SQLitePCL.Raw library via nuget to version 0.8 and then I could no longer compile the project on ios when using Xamarin and Visual Studio just kept giving me a "unhandled exception error" when the project would start.

The error from Xamarin iOS is as follows MTOUCH: error MT2002: Failed to resolve assembly: 'SQLitePCL.raw, Version=0.6.1.0, Culture=neutral, PublicKeyToken=null'

I downgraded the SQLitePCL project to 0.7.1 and then everything started compiling and working for me again. Out of curiosity I just tried upgrading the project again to 0.8.0.0 and it seems to now be working from Visual Studio when compiling over the iOS build host. Forcing nuget to remove those packages and cleaning out the proj files must have resolved it

But I still can't get it to compile in Xamarin on iOS and I get the same error above.... For now I have it working in Visual Studio so I'll try cleaning out a few things on the iOS side of things to see if it's just a bad project configuration on my side

[uwantfries]

I have had a very similar problem complier was erroring that it could not find the DLL. Android was fine. I could not get it to downgrade properly and so had to copy in the DLL from an old 7.0 backup I had lying around. BIG fudge but it got me out of this hole short term,

[pkl728]

I'm having the same issue. Can someone paste the include in their iOS csproj so I can see exactly how this should look?

[TimurZanagar]

I've got the exactly same issue. After downgrading to v0.7.0 issue solved:

Could not load file or assembly 'SQLitePCL.raw' or one of its dependencies. The system cannot find the file specified. (System.IO.FileNotFoundException) at System.AppDomain.Load (System.Reflection.AssemblyName assemblyRef, System.Security.Policy.Evidence assemblySecurity) [0x00081] in /Users/builder/data/lanes/1503/e6ebd18b/source/mono/mcs/class/corlib/System/AppDomain.cs:706 at System.AppDomain.Load (System.Reflection.AssemblyName assemblyRef) [0x00000] in /Users/builder/data/lanes/1503/e6ebd18b/source/mono/mcs/class/corlib/System/AppDomain.cs:674 at System.Reflection.Assembly.Load (System.Reflection.AssemblyName assemblyRef) [0x00000] in /Users/builder/data/lanes/1503/e6ebd18b/source/mono/mcs/class/corlib/System.Reflection/Assembly.cs:551 at ObjCRuntime.Runtime.CollectReferencedAssemblies (System.Collections.Generic.List1 assemblies, System.Reflection.Assembly assembly) [0x00019] in /Users/builder/data/lanes/1503/e6ebd18b/source/maccore/src/ObjCRuntime/Runtime.cs:218 at ObjCRuntime.Runtime.CollectReferencedAssemblies (System.Collections.Generic.List1 assemblies, System.Reflection.Assembly assembly) [0x0002c] in /Users/builder/data/lanes/1503/e6ebd18b/source/maccore/src/ObjCRuntime/Runtime.cs:220 at ObjCRuntime.Runtime.CollectReferencedAssemblies (System.Collections.Generic.List1 assemblies, System.Reflection.Assembly assembly) [0x0002c] in /Users/builder/data/lanes/1503/e6ebd18b/source/maccore/src/ObjCRuntime/Runtime.cs:220 at ObjCRuntime.Runtime.CollectReferencedAssemblies (System.Collections.Generic.List1 assemblies, System.Reflection.Assembly assembly) [0x0002c] in /Users/builder/data/lanes/1503/e6ebd18b/source/maccore/src/ObjCRuntime/Runtime.cs:220 at ObjCRuntime.Runtime.RegisterEntryAssembly (System.Reflection.Assembly entry_assembly) [0x0001b] in /Users/builder/data/lanes/1503/e6ebd18b/source/maccore/src/ObjCRuntime/Runtime.cs:200 at ObjCRuntime.Runtime.RegisterEntryAssembly (IntPtr a) [0x00000] in /Users/builder/data/lanes/1503/e6ebd18b/source/maccore/src/ObjCRuntime/Runtime.cs:158 at ObjCRuntime.Runtime.register_entry_assembly (IntPtr assembly) [0x00000] in /Users/builder/data/lanes/1503/e6ebd18b/source/maccore/runtime/Delegates.generated.cs:118 at (wrapper native-to-managed) ObjCRuntime.Runtime:register_entry_assembly (intptr)

[Krumelur]

@ericsink Is this a Xamarin problem, a Nuget issue or related directly to SQLitePCL.raw?

[ericsink]

I've been traveling with very limited network access. Back in the office next week.

E On Jun 24, 2015 6:12 AM, "René Ruppert" notifications@github.com wrote:

@ericsink https://github.com/ericsink Is this a Xamarin problem, a Nuget issue or related directly to SQLitePCL.raw?

— Reply to this email directly or view it on GitHub https://github.com/ericsink/SQLitePCL.raw/issues/48#issuecomment-114830773 .

[ericsink]

Diagnostic questions:

What version of Xamarin are you folks running?

Is anyone getting this problem without Akavache involved? (Not trying to shift blame. Just trying to eliminate a variable if possible.)

E

[Krumelur]

Akavache here.

Mono 4.0.2 ((detached/c99aa0c)
GTK+ 2.24.23 (Raleigh theme)

Xcode 6.3.1 (7703) Build 6D1002 === Xamarin.iOS === Version: 8.10.2.37 (Business Edition) === Xamarin.Mac === Version: 2.0.2.35 (Business Edition) === Xamarin.Android === Version: 5.1.4.16 (Business Edition) === Operating System === Mac OS X 10.10.3

[bordoley]

FWIW, I've encountered this in the past with apps dependent on SQLitePCL.pretty.

[ericsink]

Do you by chance have steps that show the problem?

At the moment I have been unable to reproduce this. When I start with a new project and add 0.8.0, it works. It also works when I upgrade a project from 0.7.2. I've tried both iOS and Android. My version information appears below.

I have not yet tried to repro this with Akavache involved.

I guess I also have not tried this with another PCL in play. My tests were done with a plain Xamarin Unit Tests project.

And I have not tried to repro with Visual Studio involved either.

It's possible that any of the above might be the missing variable. Or something else.

=== Xamarin Studio ===

Version 5.9.4 (build 5) Installation UUID: 60bc5529-5768-4bbd-915c-acf2deaed522 Runtime: Mono 4.0.2 ((detached/c99aa0c) GTK+ 2.24.23 (Raleigh theme)

Package version: 400020005

=== Xamarin.Android ===

Version: 5.1.4.16 (Business Edition) Android SDK: /Users/eric/Library/Developer/Xamarin/android-sdk-macosx Supported Android versions: 2.3 (API level 10) 4.0.3 (API level 15) 4.2 (API level 17) 4.4 (API level 19) 5.0 (API level 21) Java SDK: /usr java version "1.8.0_40" Java(TM) SE Runtime Environment (build 1.8.0_40-b25) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)

=== Xamarin Android Player ===

Version: Unknown version Location: /Applications/Xamarin Android Player.app

=== Apple Developer Tools ===

Xcode 6.1 (6604) Build 6A1052d

=== Xamarin.iOS ===

Version: 8.10.2.37 (Business Edition) Hash: ef8c2f7 Branch: master Build date: 2015-06-22 21:28:32-0400

=== Xamarin.Mac ===

Not Installed

=== Build Information ===

Release ID: 509040005 Git revision: 8010a90f6e246b32364e3fb46ef2c9d1be9c9a2b Build date: 2015-06-08 16:52:06-04 Xamarin addins: 7e93e9c3503f28770f23ce1b7eafd829919f18e8

=== Operating System ===

Mac OS X 10.9.5 Darwin erics-air-2.ad.sourcegear.com 13.4.0 Darwin Kernel Version 13.4.0 Sun Aug 17 19:50:11 PDT 2014 root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64

[Qonstrukt]

I"m having the same problem, and it might be related to upgrading the package. For me at least it occurs while having 0.7.0 installed and then upgrading to 0.8.0. That's with the basic package btw. (I'm also an Akavache user.) I see you tried with 0.7.2, but maybe 0.7.0 is the culprit here?

[promontis]

Also having this issue... using Akavache with Xamarin Studio And downgrading to version 7.1 works!

[ericsink]

I'll be trying again to reproduce this.

The current theory is:

(1) You start in a working state, using 0.7.whatever.

(2) You try to upgrade to 0.8.0. Then stuff stops working.

(3) You downgrade back to 0.7.whatever, and stuff works again.

I'm interested in comparing the contents of csproj and packages.config between these three states. By chance are any of you willing to post or send me copies of those files?

[Krumelur]

Here's what I can see in Xamarin Studio.

• New project
• Add Akavache (fails - cannot resolve dependency in Akavache Sqlite3)
• Add Akavache Sqlite 3 from Nuget
• This adds the dependency SqlitePCL.raw_basic (v0.7.0)

This builds and works.

SqlitePCL.raw_basic does not tell me, there is an updated version available, however I can update the package (see Gist: https://gist.github.com/Krumelur/7a887fcae24852d68e46)

I then have a SqlitePcl.raw_basic 0.8.0 but not a SqlitePcl.raw (without "basic"). The project still builds and runs.

So I think the problem really is with Akavache, using 0.7.0 (with the old name as a dependency) and maybe Visual Studio...?

[ericsink]

FWIW, the "old name" (with _basic on the end) should still work fine. SQLitePCL.raw and SQLitePCL.raw_basic have identical contents.

[ericsink]

I just tried the steps posted just above by @Krumelur

In Xamarin Studio: New project. Specifically, I chose iOS single view application.

Add Akavache sqlite3 from nuget. This works. I end up with SQLitePCL.raw_basic 0.7.0.

Xamarin Studio does report that 4 package updates are available, one of which is SQLitePCL.raw_basic.

Now I update SQLitePCL.raw_basic to 0.8.0. This works.

And after the update, the project still builds.

[Qonstrukt]

So weird, I also can't reproduce it with a clean project. I'm going to investigate some further.

[promontis]

For me, building works just fine... never had the error. However, with the new version (0.8.0) the target won't install the dll, which results in iOS using the PCL version and an error that you shouldn't use it (bait switch version). I guess Xamarin doesn't like the build script.

[Qonstrukt]

If I update the solution where it's not working I do get build errors actually; AssemblyNotFound exceptions.

[ericsink]

@Qonstrukt when you say "update the solution", what specifically do you mean?

[Qonstrukt]

Right clicking on the solution and then "Update NuGet packages".

The compile-time error only occurs once it seems. Afterwards it runs, but crashes on application start with:

Unhandled managed exception: Could not load file or assembly 'SQLitePCL.raw' or one of its dependencies. The system cannot find the file specified. (System.IO.FileNotFoundException)

Seems to me that Xamarin Studio doesn't really like the additional targets file. Probably some incompatibility with the Visual Studio spec.

[edit 1] I'm getting closer, it seems the problem is related to multiple .targets files added to my project. I had the following in there too:

"..\packages\refit.2.3.0\build\refit.targets" "..\packages\Microsoft.Bcl.Build.1.0.21\build\Microsoft.Bcl.Build.targets" "..\packages\Xamarin.Forms.1.4.3.6374\build\portable-win+net45+wp80+win81+wpa81+MonoAndroid10+MonoTouch10+Xamarin.iOS10\Xamarin.Forms.targets"

Removing those actually builds and runs, so it's probably a compatibility issue with some other package.

[edit 2] I've narrowed it down to Microsoft.Bcl.Build.targets from the Microsoft Base Class Library. Removing it builds fine, adding it back is giving me crashes. I'm going to try a clean solution now.

[ericsink]

Was this on a clean project?

Something where I could see the project tree, or maybe just the csproj?

[Qonstrukt]

This project reproduces the problems: https://github.com/Qonstrukt/SQLitePCL.raw-Test

The first time you'll get a build time exception, the builds after it will run but crash with an unmanaged exception on start-up.

[ericsink]

Update:

The project from @Qonstrukt moved me forward a bit.

I do not get the build error he describes, but if I build in release mode and try to run in the simulator I do get the crash.

(Oops. I now see that he has added some edited comments above, related to multiple targets file. I'll dig some more as well and continue this later...)

[ericsink]

Confirming: If I remove the import of Microsoft.Bcl.Build.targets, the crash goes away.

[ericsink]

FWIW:

Before checking the BCL targets file thing, I had noticed that:

Xamarin Studio seems to be doing something weird with the ResolveAssemblyReferences target. I tried putting an tag in packages/SQLitePCL.raw_basic.0.8.0/build/Xamarin.iOS10/SQLitePCL.raw_basic.targets. If I put it outside the target tag (the one that should only fire before ResolveAssemblyReferences), it causes an error on build. If put inside that target tag, it causes no problems (when the BCL targets file is also present), suggesting that my target was never getting executed.

Wondering if by chance Microsoft.Bcl.Build.targets is also trying to add a target before ResolveAssemblyReferences and Xamarin Studio can only handle one.

OTOH, I do note that the order of the two imports doesn't seem to matter. IOW, if I put the import of SQLitePCL.raw_basic.targets after the import of Microsoft.Bcl.Build.targets, it still fails.

[Qonstrukt]

I noticed the same. I've also tried removing this line from the Microsoft.Bcl.Build.targets file in case there's some version discrepancy:

<AutoUnifyAssemblyReferences>false</AutoUnifyAssemblyReferences>

But that (or setting it to true) didn't seem to have any effect.

[ericsink]

Status:

AFAICT, this is all explainable as an incompatibility with SQLitePCL.raw's targets file and Microsoft.Bcl.Build.targets.

The reason it became an issue with my 0.8.0 release is because that version moves several DLLs from the nupkg lib dir to the build dir and uses a targets file to add the reference dynamically. This was done to support multiple configurations of SQLite. For example, folks wanted the ability to use a more recent SQLite instead of the one built-in to iOS, so that, for example, they could get full text search support. SQLitePCL.raw 0.8.0 supports this, as well as certain other nice cases such as SQLCipher.

I do not currently know WHY this problem occurs.

I do not currently know if the problem is specific to Xamarin Studio or not. (I am curious about whether it happens with Visual Studio.)

It is interesting to note that searching in Google for Microsoft.Bcl.Build.targets results in lots of pages talking about compatibility problems with other nuget packages. Many people seem to have no idea what the Microsoft.Bcl.Build package does. They simply know that adding the package causes build problems and that removing the Import line seems to eliminate those build problems while not causing any new ones. I do not consider this information definitive, and I would still like a clean resolution to the issue. Nonetheless, it seems interesting and relevant that other packages apparently have related problems.

[Qonstrukt]

You might know all this, but the reason for using BCL Build is maybe a bit ironic.

Xamarin.Android, Xamarin.iOS and a lot of other frameworks don't really need Microsoft's BCL, they have their own implementation of System.Threading.Task and async for example, but Microsoft made these parts available through NuGet for frameworks which don't support hem out of the box, like Windows Phone Silverlight. (And Xamarin before when they used the Silverlight stripped version of .NET.)

So when using a PCL we often need BCL as we want to support platforms without it. When including BCL in our PCL, Microsoft wants to make sure all referencing projects are using BCL because their own native implementation might differ, and that's where BCL Build comes in action. It checks and makes sure you're including BCL in all of your packages, and that no version discrepancies arise by preventing automatic assembly binding for example.

So while it -should- lower the chance for weird assembly errors, it's actually increasing them for some packages.

It's mainly due to Xamarin.Forms that we're still supporting Silverlight in this regard, hopefully this will soon end, but for now not really feasible to drop.

[ericsink]

(grumble)

Thanks for the info.

[ericsink]

FYI:

In Microsoft.Bcl.Build.targets:

If I comment out the Target called BclBuildAddProjectReferenceProperties, the problem goes away.

Still digging...

[RickTheHat]

Any update on this or a temporary solution to get past this? I just ran into this today and my IOS won't build --> Error MT2002: Failed to resolve assembly: 'SQLitePCL.raw, Version=0.6.1.0, Culture=neutral, PublicKeyToken=null' (MT2002)

[ericsink]

The temporary solution is to manually add a reference to the appropriate SQLitePCL.raw.dll.

If removing Microsoft.Bcl.Build is an option, that should eliminate the problem.

Or, it's possible you have a different problem with a similar symptom? Let us know how it goes.

[RickTheHat]

It did build properly when I commented out what you recommended above but I worry that it's not supposed to be commented out but for now I'm able to move ahead. Thanks to everyone for your contributions.

[PureWeen]

Not sure what version you're running but 0.7.1.0 seems to run fine while still leaving the BCL things in place. I've tested this on windows phone, android, and ios (Xamarin and Visual Studio)

[ericsink]

Yes. Microsoft.Bcl.Build is apparently incompatible with any other package that uses targets files for configuration. SQLitePCL.raw 0.8 does this more than 0.7 did.

[RickTheHat]

I did revert back to the 0.7 for my IOS project and I'll go with that solution for now...TX

[bordoley]

Be warned there is a pretty nasty bug in 0.7 that impacts use of more than one connection at a time with SQLite functions that utilize callbacks.

[PureWeen]

I was hoping no one would say something like that :-/ I'm using this library via Akavache so not really sure if it's susceptible

[bordoley]

It's issue #52. I'm guessing it doesn't impact akavache which is just a SQLite-net wrapper, but you might want to write some tests to verify.

[bordoley]

Actually it's #42 but #52 is also related.

[PureWeen]

Yea and also if I'm reading through the code in Akavache correctly it only uses a single connection into the DB and all operations that persist to the DB are queue'd and performed serially.

[PureWeen]

So I was having a similar issue with the new version of Refit that seemed to have the same characteristics with BCL :-/ I added a property group to it with a CoreCompileDependsOn which seemed to clear it up... So I figured I'd try the same thing here and it seems to have cleared it up on these as well.... I added the following to the target file in the XamarinIOS10 folder and now it seems to work with the latest version of sqllite

<PropertyGroup>
<ResolveAssemblyReferencesDependsOn>
$(ResolveAssemblyReferencesDependsOn);
InjectReference_cf465a52-f6f1-4446-9f46-435c805e331b
</ResolveAssemblyReferencesDependsOn>
</PropertyGroup>

[dhaligas]

@ericsink any plans or fixes to get this to work with Akavache?

[ericsink]

AFAIK, SQLitePCL.raw does work with Akavache. If you are having trouble, please post a detailed description of the problem.

[PureWeen]

@ericsink any thoughts on adding the

<PropertyGroup>
<ResolveAssemblyReferencesDependsOn>
$(ResolveAssemblyReferencesDependsOn);
InjectReference_cf465a52-f6f1-4446-9f46-435c805e331b
</ResolveAssemblyReferencesDependsOn>
</PropertyGroup>

to the gen_build.cs output? I added that into my ios targets and now don't run into any issues around the BCL Libraries

[ericsink]

@pureween Hmmm. I do need to give that a closer look.

[ericsink]

@PureWeen Could you post the entire targets file with your modification included? Just want to make sure I'm generating the equivalent thing.

[PureWeen]

I think doing it this way makes the BeforeTargets unnecessary (didn't super test that theory though)... I just left it on there since MSBUILD will ignore the target if it already ran... So it's not like it hurts anything :-)

<?xml version="1.0" encoding="utf-8"?>
<!--Automatically generated-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

 <PropertyGroup>
    <ResolveAssemblyReferencesDependsOn>    
    $(ResolveAssemblyReferencesDependsOn);
    InjectReference_cf465a52-f6f1-4446-9f46-435c805e331b;
    </ResolveAssemblyReferencesDependsOn>
</PropertyGroup>

  <Target Name="InjectReference_cf465a52-f6f1-4446-9f46-435c805e331b" BeforeTargets="ResolveAssemblyReferences">

    <!--platform.unified_ios.pinvoke_sqlite3.anycpu-->
    <ItemGroup Condition=" ('$(UseSQLiteFrom.ToLower())' != 'packaged_sqlite3') AND ('$(UseSQLiteFrom.ToLower())' != 'packaged_sqlcipher') ">
      <Reference Include="SQLitePCL.raw">
        <HintPath>$(MSBuildThisFileDirectory)pinvoke_sqlite3\anycpu\SQLitePCL.raw.dll</HintPath>
      </Reference>
    </ItemGroup>
    <!--platform.unified_ios.pinvoke_packaged_sqlite3.anycpu-->
    <ItemGroup Condition=" '$(UseSQLiteFrom.ToLower())' == 'packaged_sqlite3' ">
      <Reference Include="SQLitePCL.raw">
        <HintPath>$(MSBuildThisFileDirectory)pinvoke_packaged_sqlite3\anycpu\SQLitePCL.raw.dll</HintPath>
      </Reference>
    </ItemGroup>
    <!--platform.unified_ios.pinvoke_packaged_sqlcipher.anycpu-->
    <ItemGroup Condition=" '$(UseSQLiteFrom.ToLower())' == 'packaged_sqlcipher' ">
      <Reference Include="SQLitePCL.raw">
        <HintPath>$(MSBuildThisFileDirectory)pinvoke_packaged_sqlcipher\anycpu\SQLitePCL.raw.dll</HintPath>
      </Reference>
    </ItemGroup>
  </Target>
</Project>