App extensions include multiple copies of the Xamarin framework

[bocciab]

Steps to Reproduce

1. Download the ExtensionSamples sample project
2. Build in Debug or Release config
3. Observe the file size of the resulting app bundle
4. Remove references to the app extensions and rebuild
5. Observe the size of the resulting app bundle

Expected Behavior

Should be comparable

Actual Behavior

The final size of the app bundle with the extensions is almost 8x the bundle size without them

Note: In my case, in order to get a release build to succeed, I had to remove the ShareExtension project as I just couldn't get it to take my provisioning profile. The TodayExtension and FinderSyncExtension projects were fine with it. In this config, the app bundle size with the extensions was 23.9 MB. When I removed references to the two remaining extensions it was 3.1 MB - The two extensions increased the size by 770%. I should at least think the app would be the larger portion.

.Net does allow giving the runtime hints on where to look for binaries, so maybe this could be used. Clear any of the appex projects of the framework and assign a search path that points to the main bundle's MonoBundle folder?

Environment

=== Visual Studio Community 2017 for Mac ===

Version 7.7.2 (build 21)
Installation UUID: 2b97445f-3138-44e3-9acb-2ef360286f5f
	GTK+ 2.24.23 (Raleigh theme)
	Xamarin.Mac 4.4.1.178 (master / eeaeb7e6)

	Package version: 516000221

=== Mono Framework MDK ===

Runtime:
	Mono 5.16.0.221 (2018-06/b63e5378e38) (64-bit)
	Package version: 516000221

=== NuGet ===

Version: 4.8.0.5385

=== .NET Core ===

Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
	2.1.2
	2.1.1
SDK: /usr/local/share/dotnet/sdk/2.1.302/Sdks
SDK Versions:
	2.1.302
	2.1.301
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/5.16.0/lib/mono/msbuild/15.0/bin/Sdks

=== Xamarin.Profiler ===

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

=== Xamarin.Android ===

Not Installed

=== Android Device Manager ===

Version: 7.7.1.0
Hash: 06ceaea1

=== Apple Developer Tools ===

Xcode 10.1 (14460.46)
Build 10B61

=== 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

=== Xamarin.Mac ===

Version: 5.2.1.12 (Visual Studio Community)
Hash: 65ec520f
Branch: 
Build date: 2018-12-05 12:06:09-0500

=== Xamarin.iOS ===

Version: 12.2.1.12 (Visual Studio Community)
Hash: 65ec520f
Branch: d15-9
Build date: 2018-12-05 12:06:09-0500

=== Build Information ===

Release ID: 707020021
Git revision: f1fea53df9eb0bb5890a9563c0d7ea7b03922144
Build date: 2018-12-14 18:37:35+00
Build branch: release-7.7
Xamarin extensions: 9c5cea335e6a9ce4ccfde31c4aa06c25a3576085

=== Operating System ===

Mac OS X 10.14.0
Darwin 18.0.0 Darwin Kernel Version 18.0.0
    Wed Aug 22 20:13:40 PDT 2018
    root:xnu-4903.201.2~1/RELEASE_X86_64 x86_64

=== Enabled user installed extensions ===

NuGet Package Management Extensions 0.14

Build Logs

https://gist.github.com/bocciab/17e73f6b50ab16b2ab88e5265f0a208f

Example Project (If Possible)

ExtensionSamples provided by VSMac team was used.

[spouliot]

Similar logic exists in Xamarin.iOS. It's a bit more tricky that it looks like since sharing implies most build options (e.g. AOT) must be identical (across all projects [1]) otherwise assemblies can't be reused.

Also deduplicating cannot work in a few other cases, e.g. using a different versions of a 3rd party library (which is more common that expected) between projects.

[1] if you see an 770% increase it's likely because the main app is linked and the extensions are not (which is also something, linking, that needs to be aware of code sharing across projects).

[bocciab]

For my purposes, I keep all of my projects on the same versions of 3rd party packages.

If there is a known workaround I could use until this improvement is available, that would make me really happy.

[spouliot]

Not exactly a known workaround but, in theory, you could write a small script that detects duplicated files and replace them with symlinks.

This assume that all your build options are identical between your main application and all its extensions and that anything that modify assemblies, e.g. our managed linker, are disabled.

Note that such changes will break existing code signatures and that you'll need to re-sign everything (extensions and application) properly.

If you try this then please et us know your results :-)

[rolfbjarne]

Closing in favor of #10051 (which is for .NET projects).