Xamarin-android: XA3001: Could not AOT the assembly: System.Runtime.Loader.dll

Created on 27 May 2020 · 4Comments · Source: xamarin/xamarin-android

Steps to Reproduce

Enable AOT Compilation on release build

<OutputPath>bin\SIT\</OutputPath>
<Optimize>true</Optimize>
<DebugType>none</DebugType>
<AssemblyName>AppName.Mobile.Droid.SIT</AssemblyName>
<DefineConstants>
</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<AndroidUseSharedRuntime>False</AndroidUseSharedRuntime>
<EmbedAssembliesIntoApk>True</EmbedAssembliesIntoApk>
<Debugger>Xamarin</Debugger>
<RunCodeAnalysis>false</RunCodeAnalysis>
<AndroidSupportedAbis>armeabi-v7a</AndroidSupportedAbis>
<AndroidEnableMultiDex>true</AndroidEnableMultiDex>
<AotAssemblies>true</AotAssemblies>
<EnableLLVM>true</EnableLLVM>
<AndroidEnableProfiledAot>false</AndroidEnableProfiledAot>
<BundleAssemblies>false</BundleAssemblies>
<MandroidI18n />
<AndroidDexTool>d8</AndroidDexTool>
<AndroidLinkTool>r8</AndroidLinkTool>
<AndroidStoreUncompressedFileExtensions>
</AndroidStoreUncompressedFileExtensions>
<AndroidEnableSGenConcurrent>true</AndroidEnableSGenConcurrent>
<AndroidLinkMode>SdkOnly</AndroidLinkMode>
<DebugSymbols>false</DebugSymbols>

Attempt to Run on Android Device from Windows

Expected Behavior

Builds and deploys

Actual Behavior

Error XA3001: Could not AOT the assembly: System.Runtime.Loader.dll 0

Version Information

Microsoft Visual Studio Enterprise 2019 (2)
Version 16.6.0
VisualStudio.16.Release/16.6.0+30114.105
Microsoft .NET Framework
Version 4.8.03761

Installed Version: Enterprise

Azure App Service Tools v3.0.0 16.6.936.3669
Azure App Service Tools v3.0.0

C# Tools 3.6.0-4.20251.5+910223b64f108fcf039012e0849befb46ace6e66
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Common Azure Tools 1.10
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

Extensibility Message Bus 1.2.0 (d16-2@8b56e20)
Provides common messaging-based MEF services for loosely coupled Visual Studio extension components communication and integration.

IntelliCode Extension 1.0
IntelliCode Visual Studio Extension Detailed Info

JetBrains ReSharper Ultimate 2020.1.3 Build 201.0.20200515.122017
JetBrains ReSharper Ultimate package for Microsoft Visual Studio. For more information about ReSharper Ultimate, visit http://www.jetbrains.com/resharper. Copyright © 2020 JetBrains, Inc.

Microsoft JVM Debugger 1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines

Microsoft MI-Based Debugger 1.0
Provides support for connecting Visual Studio to MI compatible debuggers

Mono Debugging for Visual Studio 16.6.17 (9692114)
Support for debugging Mono processes with Visual Studio.

NuGet Package Manager 5.6.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/

ProjectServicesPackage Extension 1.0
ProjectServicesPackage Visual Studio Extension Detailed Info

Visual Basic Tools 3.6.0-4.20251.5+910223b64f108fcf039012e0849befb46ace6e66
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Visual F# Tools 10.9.1.0 for F# 4.7 16.6.0-beta.20217.4+1c969cac25e2d38d71872efe6c8226029e42bb59
Microsoft Visual F# Tools 10.9.1.0 for F# 4.7

Visual Studio Code Debug Adapter Host Package 1.0
Interop layer for hosting Visual Studio Code debug adapters in Visual Studio

VisualStudio.DeviceLog 1.0
Information about my package

VisualStudio.Foo 1.0
Information about my package

VisualStudio.Mac 1.0
Mac Extension for Visual Studio

Xamarin 16.6.000.1055 (d16-6@2873694)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin Designer 16.6.0.318 (remotes/origin/d16-6@66afc5421)
Visual Studio extension to enable Xamarin Designer tools in Visual Studio.

Xamarin Templates 16.6.40 (1f1466f)
Templates for building iOS, Android, and Windows apps with Xamarin and Xamarin.Forms.

Xamarin.Android SDK 10.3.1.0 (d16-6/3fe860a)
Xamarin.Android Reference Assemblies and MSBuild support.
Mono: 165f4b0
Java.Interop: xamarin/java.interop/d16-6@2cab35c
ProGuard: xamarin/proguard/master@905836d
SQLite: xamarin/sqlite/3.31.1@49232bc
Xamarin.Android Tools: xamarin/xamarin-android-tools/d16-6@bfb66f3

Xamarin.iOS and Xamarin.Mac SDK 13.18.1.31 (b3eedfe)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.

Log File

logs.zip

App+Library Build

Source

EDMIStephen

Most helpful comment

Glad that did the trick! Thanks to the earlier temporary reply that mentioned xamarin/xamarin-macios#3199, I tried the <ExcludeAssets> approach for this System.Runtime.Loader scenario, and it worked as desired, so that is probably a preferable workaround for this case too since it avoids having to tinker with the cached copy of the NuGet package.

Improved workaround

Open the _.csproj_ file for the affected Android app project in a text editor.

Under the <PropertyGroup> element that contains other <PackageReference> elements, add an explicit <PackageReference> element for System.Runtime.Loader, and set the ExcludeAssets metadata to all:
<PackageReference Include="System.Runtime.Loader" Version="4.3.0"> <ExcludeAssets>all</ExcludeAssets> </PackageReference>

Explanation: This has the same desired end result as copying the _MonoAndroid10_.__ placeholder into the _ref_ directory. It tells the build not to use the _System.Runtime.Loader.dll_ reference assembly, which is fine for Xamarin.Android projects.

That has worked on our Mac build machines too so that is a nicer workaround.

Thanks for your time.

EDMIStephen on 11 Jun 2020

👍2

All 4 comments

I believe the underlying problem in this case is https://github.com/xamarin/xamarin-android/issues/3016. That is, the old System.Runtime.Loader NuGet package (last updated in 2016) has an uncommon structure that led to a special-case workaround in https://github.com/xamarin/xamarin-android/commit/fcb8364e35820edf8ec158b17e1a1814180f70ae. But that special-case workaround wasn't 100% correct because it causes the reference assembly from the NuGet package to be included in the final app package. Reference assemblies should only be used during compilation and _not_ packaged into the final app packages.

Since reference assemblies are not expected to be packaged into apps, I'm not sure the AOT compiler is intended to be able to compile them, but I'll let @radekdoulik weigh in on whether handling reference assemblies sounds like a scenario the Mono team should consider adding to the AOT compiler.

In the mean time, I'll surface the idea I found in https://github.com/xamarin/xamarin-android/issues/3016 as a candidate workaround. I did a quick local test with this and believe it is a valid workaround for this AOT issue as well.

Candidate workaround

Run a command similar to the following in a Windows PowerShell command prompt to copy the _MonoAndroid10\_.__ placeholder to the _ref_ directory of the System.Runtime.Loader NuGet package:
```
Copy-Item -Recurse "$env:USERPROFILE\.nuget\packages\system.runtime.loader\4.3.0\lib\MonoAndroid10" "$env:USERPROFILE\.nuget\packages\system.runtime.loader\4.3.0\ref\"
```
Delete _obj\project.assets.json_ from the Android app output directories (or just delete the whole _obj_ and _bin_ directories) and rebuild the app.

Explanation: The _System.Runtime.Loader.dll_ reference assembly does not serve a purpose in Xamarin.Android apps and so can be excluded entirely from the build process. Excluding it allows the _System.Runtime.Loader.dll_ facade assembly to be included correctly in the app package instead.

brendanzagaeski on 29 May 2020

That seems to work on at least my local env.

EDMIStephen on 4 Jun 2020

Glad that did the trick! Thanks to the earlier temporary reply that mentioned https://github.com/xamarin/xamarin-macios/issues/3199, I tried the <ExcludeAssets> approach for this System.Runtime.Loader scenario, and it worked as desired, so that is probably a preferable workaround for this case too since it avoids having to tinker with the cached copy of the NuGet package.

Improved workaround

Open the _.csproj_ file for the affected Android app project in a text editor.
Under the <PropertyGroup> element that contains other <PackageReference> elements, add an explicit <PackageReference> element for System.Runtime.Loader, and set the ExcludeAssets metadata to all:
```
<PackageReference Include="System.Runtime.Loader" Version="4.3.0">
 <ExcludeAssets>all</ExcludeAssets>
</PackageReference>
```

Explanation: This has the same desired end result as copying the _MonoAndroid10\_.__ placeholder into the _ref_ directory. It tells the build not to use the _System.Runtime.Loader.dll_ reference assembly, which is fine for Xamarin.Android projects.

brendanzagaeski on 4 Jun 2020

❤1 👍1

Glad that did the trick! Thanks to the earlier temporary reply that mentioned xamarin/xamarin-macios#3199, I tried the <ExcludeAssets> approach for this System.Runtime.Loader scenario, and it worked as desired, so that is probably a preferable workaround for this case too since it avoids having to tinker with the cached copy of the NuGet package.

Improved workaround

Open the _.csproj_ file for the affected Android app project in a text editor.

Under the <PropertyGroup> element that contains other <PackageReference> elements, add an explicit <PackageReference> element for System.Runtime.Loader, and set the ExcludeAssets metadata to all:
<PackageReference Include="System.Runtime.Loader" Version="4.3.0"> <ExcludeAssets>all</ExcludeAssets> </PackageReference>

Explanation: This has the same desired end result as copying the _MonoAndroid10_.__ placeholder into the _ref_ directory. It tells the build not to use the _System.Runtime.Loader.dll_ reference assembly, which is fine for Xamarin.Android projects.