Efcore: Exception while loading assemblies - FileNotFoundException - Could not load assembly System.Memory

[ChkonCSD]

Good day. I;m trying to create simple Xamarin Forms app (3.0.0.482510) - iOS, Android + .net Standard projects. I've added Microsoft.EntityFrameworkCore.Sqlite (2.1.0-rc1-final) to all projects. there is no issues with building common project, but when I'm trying to build Android I have build error with following exception:
`` Error Exception while loading assemblies: System.IO.FileNotFoundException: Could not load assembly 'System.Memory, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. Perhaps it doesn't exist in the Mono for Android profile? File name: 'System.Memory.dll' at Java.Interop.Tools.Cecil.DirectoryAssemblyResolver.Resolve(AssemblyNameReference reference, ReaderParameters parameters) at Xamarin.Android.Tasks.ResolveAssemblies.AddAssemblyReferences(DirectoryAssemblyResolver resolver, ICollection1 assemblies, AssemblyDefinition assembly, Boolean topLevel)
at Xamarin.Android.Tasks.ResolveAssemblies.Execute(DirectoryAssemblyResolver resolver) XF3EFCTest.Android C:\VisualStudio\2017\Enterprise\MSBuild\XamarinAndroid\Xamarin.Android.Common.targets 1590

Visual studio - 15.7.1

[ajcvickers]

@divega to follow up with Xamarin

[ChkonCSD]

If you want I can give you my test solution

[azabluda]

I ran into the same problem and used the following workaround https://github.com/azabluda/InfoCarrier.Core/commit/30abe4238050b64ed37134902da01f8d58040426

[ChkonCSD]

@ajcvickers Good day! Thanks, I've tried your workaround, but it seems doesn't work for me.

[ToddThomson]

I utilize Microsoft.EntityFrameworkCore.Sqlite in a NetStandard 2 common library for data services for both Xamarin.Android and Xamarin.IOS. I just updated to EFCore.Sqlite to release 2.1. I now get the build error as above.
I have a question...
How can something like this happen? Xamarin.Android is NetStandard v2.0 compatible and EFCore.Sqlite 2.1 is NetStandard v2.0 compatible. Aren't they both guaranteed to support the same APIs? Perhaps my assumption that Xamarin.Android is NetStandard v2.0 compatible is wrong (or EFCore Sqlite support is not NetStandard compatible).

Is there a Xamarin.Android ( and Xamarin.IOS ) (pre)release that supports system.memory 4.0.1?

[ToddThomson]

Workaround: copy System.Memory.dll from ../Xamarin.iOS/v1.0/Fascades to ../Xamarin.Android/v1.0/Fascades ( in your vs2017 Community 15.7.2 installation ).

NOTE: This workaround is NOT required for VS2017 15.7.3 or greater.

[dgerding]

I'm getting the same behavior. Going to try the workaround. Thanks @ToddThomson . Anyone else have any luck with it?

[ConX-Ryan]

Im in the same position, it seems that the writing has been on the wall since April about this one. Pity there was not more coordination for a smooth release and upgrade.

[(https://github.com/aspnet/SignalR/issues/1886)]

EDIT: 15.7.3 fixes and was only a day later so all in all it was pretty smooth; i withdraw previous statement ⚙️

[divega]

@marek-safar FYI, this is one of two System.Memory-related issues reported to block EF Core 2.1 RTM from working on Xamarin. The other one is https://github.com/xamarin/xamarin-macios/issues/4168. I am assuming that they maybe separate issues because the errors are different.

Would it be better if we move this one to a Xamarin repo?

FWIW, the dependency on System.Memory comes indirectly through Microsoft.Extensions.Primitives.

Do you know if the fix for https://github.com/dotnet/corefx/issues/29847 would fix this too?

[cwrea]

After encountering a similar issue with Xamarin.iOS, I tried my case in a Xamarin.Android project. Also fails with EF Core 2.1 due to dependency on newer System.Memory. Here's the issue I just filed for Xamarin.Android: Android app build fails when referencing package (e.g. Entity Framework Core 2.1) that depends on newer System.Memory.

[ToddThomson]

I can confirm that VS 2017 15.7.3 fixes this issue ( at least for Xamarin.Android app builds ).

Before installing the 15.7.3 update I removed my workaround as mentioned above.

[marek-safar]

@divega I'd certainly try if that fix resolves the issue as well and it's quite possible. If you please open Xamarin issue with repro.

Thanks

[divega]

If you please open Xamarin issue with repro.

@marek-safar Thanks. I think @cwrea beat me to it: https://github.com/xamarin/xamarin-android/issues/1769. And that one is already closed because it doesn't repro anymore in 15.7.3 due to changes made for Android.

I will go ahead and close this issue as external since the only actionable item left on the EF Core side is the missing testing for Xamarin (https://github.com/aspnet/EntityFrameworkCore/issues/8792) which could have helped detect this sooner.

[divega]

Reopening and assigning to @smitpatel who is going to do some testing for the fix.

[smitpatel]

Testing with pre-release 2.1.1 bits shows that it is not going to fixed for first patch for iOS.
For android latest version of VS will fix the issue.
VS for Mac 7.5.2 build 40

[cwrea]

I think the meta-issue here (and https://github.com/xamarin/xamarin-macios/issues/4168 and https://github.com/xamarin/xamarin-android/issues/1769) is that packages like EF Core 2.1 (and SignalR, https://github.com/aspnet/SignalR/issues/1886) took what have turned out to be hard dependencies (whether direct, or indirect) on new package bits from .NET Core 2.1—package bits which are neither present in .NET Standard 2.0 nor yet truly available for other Standard-conforming platforms.

By "truly available" above, I don't just mean published—because as evidenced (and perhaps in error), Microsoft.Extensions.* and System.* packages can be published on NuGet while claiming "No dependencies" on supported platforms like Xamarin.iOS and Xamarin.Android, and yet those underlying "supported" platforms could be missing the actual implementation that the package asserted¹ would be there.

And so developers of Standard-conforming platforms other than .NET Core (which got these new APIs first) now have to play catch-up just to get back to compatibility—compatibility not with the Standard itself, but with the new bits now required by new releases of these popular libraries that had cross-platform as a goal.

Perhaps it may not be reasonable to expect Xamarin.iOS and Xamarin.Android to simultaneously get new APIs as they are added to .NET Core. The Xamarin mobile platform developers are already tasked with keeping up with what Google is doing with Android, and what Apple is doing with iOS. And iOS 12, in particular, is probably top-of-mind for the next couple of Xamarin.iOS releases. There are far more Xamarin app developers who'd be upset if the latest UIKit weren't supported in the product vs. those of us eager to take advantage of the new Entity Framework Core release.

Perhaps it may also not be reasonable to expect the .NET Standard itself to get revved as every useful new API is added to .NET Core. There's a discussion about this here: https://github.com/dotnet/standard/issues/682.

So maybe developers of packages who desire to maintain cross-platform² compatibility could be more conservative in adopting features from .NET Core that aren't yet truly available on other platforms that the package would like to maintain compatibility with? Or adopt a strategy whereby new bits can be taken advantage of when present, but not break compatibility when not present?

TL;DR: As the complexity of a package increases, the likelihood that cross-platform capability comes as free side-effect quickly approaches zero. :/

---

¹ "asserted" by use of a _._ placeholder file (https://github.com/aspnet/Home/issues/744) within the package's lib subfolder for the supported platform.

² "cross-platform" is meant as in across multiple target frameworks that conform to a specific .NET Standard version, and not just across the handful of desktop and server OSs you get by targeting only .NET Core.

[ToddThomson]

@cwrea As pointed out in issue 682 in dotnet/standard, New ,NET Core releases will always have an increasing/changing API surface that is a superset of .NET Standard. This is excellent - use newer bits and get any and all benefits. For developers, we choose a target framework(s) for the API surface we need for the platforms our software will run on.

Release 2.1 of EFCore took a dependency on Microsoft.Extensions.Logging 2.1 which in its dependency chain uses System.Memory 4.5 ( Options->Primitives ). Now, I have no idea whether the System.Memory 4.5 API is part of .NET Standard v2. It might be (.NET Standard 1.1); it might be part of the latest bits from .NET Core. I shouldn't have to know! When I take a dependency in my code I only look at the nuget dependencies ( or rather, I'm hoping that my dev tools do the job ). If I am targeting .NET Standard 2 then I should expect that ALL my dependencies ( and their dependency chain) target .NET Standard 2. That is the beauty of .NET Standard!

At least with Xamarin.Android ( before its release update in VS 2017 v15.7.3 ) System.Memory was not included. This was just a bug. It was reported and fixed. With the current release cadence of VS 2017 I can live with that.

EF Core 2.1 targets .NET Standard 2. It should be compatible with any platform that supports .NET Standard 2. If .NET Standard platforms are missing required implementation packages then that is a bug. If a published package doesn't properly identify its target framework then that is a bug.

Before a nuget package is released it should be tested on all .NET platforms that support the package's target framework. With EF Core 2.1, it appears that this is not yet the case. This is a bit troubling as the great .NET Standard 2 changes have been in place for a while now.

[cwrea]

@ToddThomson Re:

If I am targeting .NET Standard 2 then I should expect that ALL my dependencies ( and their dependency chain) target .NET Standard 2. That is the beauty of .NET Standard!

I agree completely. As an app developer, this is the ideal. Platform developers and library developers have to be more concerned about the details, but what you wrote is the way I wish it to be at the app development level. I know there will be bugs and it will never be perfect, but things can get closer to that ideal than where we are today.

BTW, I elaborated on the Standard and the dependency chain issue at https://github.com/dotnet/standard/issues/682#issuecomment-395486228, just after my comment above on this issue. Looks like there's more than one path that leads to the dependency on System.Memory.

And re: "EF Core 2.1 targets .NET Standard 2." ... in theory, but there's work to do (as you know, having commented there too) before I'll feel more confident in that holding true. .NET Standard is so much more than .NET Framework and .NET Core.

Anyway, crossing my fingers! EF Core is relevant for mobile app development scenarios, esp. w.r.t. code sharing opportunities with the server side. Not all the same concerns on client vs. server, but there are certainly places where sharing can make sense.

[ErikEJ]

Is this not on wrong milestone (2.1.1) ?

[ajcvickers]

Moving this to 2.1.3 to verify as part of that release.

[cwrea]

While https://github.com/xamarin/xamarin-android/issues/1769 has been closed and 15.7.3 did address a build issue with Xamarin.Android and EF Core 2.1, I discovered that enabling the Xamarin.Android linker, even with the conservative "SdkOnly" setting (i.e. not user assemblies), is causing a new problem. I just opened the following issue:

• xamarin/xamarin-android - Android app build fails during "SdkOnly" linking when referencing package (e.g. Entity Framework Core 2.1) that depends on newer System.Memory #1813.

On the Xamarin.iOS end of things, https://github.com/xamarin/xamarin-macios/issues/4168 remains a blocking issue.

[smitpatel]

This issue is fixed in upcoming release of Xamarin.