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

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, ICollection`1 assemblies, AssemblyDefinition assembly, Boolean topLevel)
   at Xamarin.Android.Tasks.ResolveAssemblies.Execute(DirectoryAssemblyResolver resolver)	XF3EFCTest.Android	C:\VisualStudio\2017\Enterprise\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets	1590	

Visual studio - 15.7.1

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 22 (8 by maintainers)

Most upvoted comments

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 on May 30, 2018

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.

cwrea on Jun 13, 2018

@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.

cwrea on Jun 7, 2018