What is the Significance of .exe & monobundle in .framework for iOS project?

[Goldie13]

Steps to Reproduce

1. I have created the sample C# project(LibCheckForSize) which two dependent projects (Project_1 & Project_2) referred.
2. Configured embeddinator for arm64 cpu architecture
3. Actual LibCheckForSize.dll size is 4kb & LibCheckForSize.framework size is 11.7 which is too much
4. Only arm64 architecture for iphoneOS & Simulator is selected.
5. Inside .framework it consists: Headers (3Kb),Info.plist (2Kb),LibCheckForSize.exe(9.2Mb),MonoBundle(2.4Mb) & NOTICE(159bytes)

Expected Behavior

Size should be less

Actual Behavior

Framework size is too much. In that LibCheckForSize.exe(9.2Mb) itself is very bulky. what is significance of .exe & monobundle folder in framework????? And why LibCheckForSize.aotdata.arm64 & LibCheckForSize.pdb files are generated in monobundle & what is it signifies????

Environment

Visual Studio Community 2019 for Mac
Version 8.4.8 (build 2)
Installation UUID: 24ba63ab-14ee-4aa9-9af8-881247a084b1
    GTK+ 2.24.23 (Raleigh theme)
    Xamarin.Mac 5.16.1.25 (issue-7441-d16-3-vsmac / 881172e73)

    Package version: 606000166

Mono Framework MDK
Runtime:
    Mono 6.6.0.166 (2019-08/d9001b5ae70) (64-bit)
    Package version: 606000166

Roslyn (Language Service)
3.4.0-beta4-19562-05+ff930dec4565e2bc424ad3bf3e22ecb20542c87d

NuGet
Version: 5.3.0.6192

.NET Core SDK
SDK: /usr/local/share/dotnet/sdk/3.1.102/Sdks
SDK Versions:
    3.1.102
    3.1.101
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/6.6.0/lib/mono/msbuild/Current/bin/Sdks

.NET Core Runtime
Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
    3.1.2
    3.1.1
    2.1.15

Xamarin.Profiler
Version: 1.6.13.11
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

Updater
Version: 11

Apple Developer Tools
Xcode 11.3.1 (15715)
Build 11C505

Xamarin.Mac
Version: 6.10.0.21 (Visual Studio Community)
Hash: 02c4b3bdc
Branch: xcode11.3
Build date: 2020-02-18 14:13:31-0500

Xamarin.iOS
Version: 13.10.0.21 (Visual Studio Community)
Hash: 02c4b3bdc
Branch: xcode11.3
Build date: 2020-02-18 14:13:32-0500

Xamarin.Android
Not Installed

Microsoft Mobile OpenJDK
Java SDK: Not Found

Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

Android SDK Manager
Version: 16.4.0.10
Hash: 2c49a7d
Branch: remotes/origin/d16-4
Build date: 2020-02-20 19:25:52 UTC

Android Device Manager
Version: 16.4.0.32
Hash: 7a5cb8b
Branch: remotes/origin/d16-4
Build date: 2020-02-20 19:26:14 UTC

Xamarin Designer
Version: 16.4.0.479
Hash: 074544417
Branch: remotes/origin/d16-4
Build date: 2020-01-22 22:50:22 UTC

Xamarin Inspector
Version: 1.4.3
Hash: db27525
Branch: 1.4-release
Build date: Mon, 09 Jul 2018 21:20:18 GMT
Client compatibility: 1

Build Information
Release ID: 804080002
Git revision: 4f35aa7e44fb398379e512d0bfd6f8df8d34b5ac
Build date: 2020-02-27 16:16:52+00
Build branch: release-8.4
Xamarin extensions: 4f35aa7e44fb398379e512d0bfd6f8df8d34b5ac

Operating System
Mac OS X 10.15.2
Darwin 19.2.0 Darwin Kernel Version 19.2.0
    Sat Nov  9 03:47:04 PST 2019
    root:xnu-6153.61.1~20/RELEASE_X86_64 x86_64

Build Logs

Example Project (If Possible)

LibCheckForSize.zip Project_1.zip Project_2.zip

[chamons]

This is really a technical question and not an issue but I'll answer anyway:

Without a built framework I can't answer specifics, but to understand what's going on let's talk about .NET:

• Even the simplest .NET library has a number of dependent .NET libraries it pulls in. Things like System.dll, mscorlib.dll, and such. Since bundled frameworks pull in all of their dependencies, we have to include them, so you can run on systems without mono installed. You'll see those in MonoBundle
• On top of that, we have to bundle in the runtime itself. Things like the garbage collector, and the runtime support pieces. Those are also in MonoBundle.
• iphoneOS and Simulator are two different architectures, so we have to double all of the native bits (one copy for x86_64, one for arm64)
• On iphoneOS we don't have access to a JIT, so we have to AOT the managed libraries. This produces binaries that are significantly larger than the managed IL assemblies.

This all can produce large frameworks. However consuming application will only bundle in the requires slices in most cases.