Xamarin-android: System.Memory facade is missing from the installation

[marek-safar]

This breaks when newer System.Memory package is used. Xamarin.iOS installs it correctly, see https://github.com/dotnet/corefx/issues/29654

VS bug #619210

[brendanzagaeski]

Cross-referencing notes for the Microsoft team

I suspect the following item from Visual Studio Developer Community matches this issue: https://developercommunity.visualstudio.com/content/problem/252454/systemiofilenotfoundexception-could-not-load-assem.html

Also note that this facade was added to xamarin-android/master in https://github.com/xamarin/xamarin-android/pull/1509.

[marek-safar]

We'll need this for dev15-9 and newer only

[MarcosCobena]

In the meantime anyone having this issue can, in a hackish flavour, manually reference System.Drawing NuGet's DLL for .NET Standard 2.0 profile. I'm doing it right now with xUnit's Android Runner and seems to work, although I'm not really proud of. Anyway, my 2 cents :-)

[tlhintoq]

How is it the issue in NuGet is marked closed if the problem still exists and is under investigation on DeveloperCommunity?
https://developercommunity.visualstudio.com/content/problem/252454/systemiofilenotfoundexception-could-not-load-assem.html

I'm having the same System.Memory not found problem today 04jun2018, with VS2017 v15.7.2 - latest everything - everything updated. Visual Studio solution looks happy with no alerts, yet can't load System.Memory.
All after migrating from Packages.config to PackagesReferences.

So is this issue resolved as is indicated by the nuget issues, or under investigation as indicated by Microsoft? Is there a viable work-around/patch/hack? Or do I just roll the entire solution back to Packages.config until PackagesReferences can be made to work?

https://forums.xamarin.com/discussion/127584/could-not-load-system-memory-dll-after-migrating-from-package-config-to-packagesreference#latest

[brendanzagaeski]

Verification status: The System.Memory facade is now present in the latest servicing update for Visual Studio 2017 version 15.7

As a caution about this verification status, the System.Memory facade assembly for Xamarin.Android in Visual Studio 2017 version 15.7.3 only has type forwarders for a _subset_ of the types from the System.Memory NuGet package. See the Facades/System.Memory/TypeForwarders.cs file from the mono/2017-12 branch. The types that are commented-out will have type resolution errors in Xamarin projects. Those types are not yet implemented as built-in types in the mono/2017-12 branch (or the corresponding xamarin-android/d15-7 and xamarin-macios/15-7 branches).

(Note to @tlhintoq: The fact that some type forwarders are commented-out in the facade assembly would _not_ account for the error message from your screenshot where the error indicates that the _whole assembly_ cannot be found. I haven't had a chance to experiment with the details presented in your forum thread, so I don't have additional insight on that error yet. It might be a somewhat separate issue, perhaps specific to PackageReference vs. packages.config.)

Plan for the xamarin-android/d15-8 branch and the next version of the System.Memory NuGet package

The System.Memory facade assembly has been intentionally taken back _out_ of mono/2018-02@65d719d1 and the built-in types have been changed to internal in mono/2018-02@21716f8b (and xamarin-android/d15-8 and xamarin-macios/d15-8). This will allow users to build and run Xamarin projects against the type-complete .NET Standard 2.0 implementation of the System.Memory assembly from the NuGet package rather than the incomplete built-in implementation in Mono. Those changes will be included in published builds starting with the upcoming Visual Studio 2017 version 15.8 Preview 3.

(The placeholder files for Xamarin project types in the System.Memory NuGet package are also being removed temporarily so that the NuGet package manager will automatically install the .NET Standard 2.0 implementation of the System.Memory assembly into Xamarin projects. Users who update to Visual Studio 2017 version 15.8 Preview 3 or newer will need to install that upcoming new version of the System.Memory NuGet package or manually reference the lib\netstandard2.0\System.Memory.dll file from the current System.Memory version 4.5.0 NuGet package.)

Plan for the xamarin-android/d15-9 branch and the future System.Memory NuGet package

The future d15-9 Xamarin SDK branches will be based on a version of Mono that has built-in implementations of _all_ the types from the System.Memory NuGet package, so the System.Memory facade will be added back to the Xamarin SDKs (this time with _all_ of the type forwarders), and the placeholder files will be added back to the System.Memory NuGet package for Xamarin project types.

---

Additional verification details, including the install location of the System.Memory facade assembly

Results with Visual Studio 2017 version 15.7.3 and Xamarin.Android version 8.3.3.3

The System.Memory.dll facade assembly is present in the expected location.

Windows:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\MonoAndroid\v1.0\Facades\System.Memory.dll

Mac:

/Library/Frameworks/Xamarin.Android.framework/Versions/8.3.3-2/lib/xamarin.android/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Memory.dll

Results with the previous versions (Visual Studio 2017 version 15.7.2 and Xamarin.Android version 8.3.0.19)

The System.Memory.dll facade assembly is _not_ present.

Windows:

C:\> dir /B "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\MonoAndroid\v1.0\Facades\System.Memory.dll"
File Not Found

Mac:

$ ls /Library/Frameworks/Xamarin.Android.framework/Versions/8.3.0-19/lib/xamarin.android/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Memory.dll
ls: /Library/Frameworks/Xamarin.Android.framework/Versions/8.3.0-19/lib/xamarin.android/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Memory.dll: No such file or directory

---

[tlhintoq]

@brendanzagaeski
I haven't had a chance to experiment with the details presented in your forum thread, so I don't have additional insight on that error yet. It might be a somewhat separate issue, perhaps specific to PackageReference vs. packages.config.)

I can see that. Yesterday was the first time I tried PackageReferences in an attempt to resolve a different issue. I later saw a mention someplace that because if the issues _it_ causes that the VS Templates were rolled back to package.config. I guess that action is all that statement needed about PackageReferences, currently.

Thanks for looking into the issue. I know you guys have 1,000 spinning plates in the air at the same time and not enough hands to manage them all.

[mauro-codes]

Seems to be fixed in the last VS version. I just updated and the problem disappear.