Bug 58873 - Invalid iOS extensions compilation when use shared class library: dll is not included in output package
Summary: Invalid iOS extensions compilation when use shared class library: dll is not ...
Alias: None
Product: iOS
Classification: Xamarin
Component: General (show other bugs)
Version: XI 10.12 (d15-3)
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: 15.8
Assignee: Rolf Bjarne Kvinge [MSFT]
Depends on:
Reported: 2017-08-18 08:41 UTC by Petr Kovalev
Modified: 2018-03-02 08:43 UTC (History)
4 users (show)

See Also:
Is this bug a regression?: No
Last known good build:


Description Petr Kovalev 2017-08-18 08:41:46 UTC
# Steps to reproduce
Create a solution with two Xamarin.iOS extension projects (Share and Action extensions in our case). Add a Xamarin.iOS class library project to solution. Reference this project from both iOS extensions projects and perform calls to this library from both extension projects. Compile the solution.

# Expected behavior
In compiled package each iOS extension project becomes a separate package that includes shared compiled dll.

# Actual behavior
In compiled package each iOS extension project becomes a separate package but only one of them contains shared compiled dll. Another extension does not contain shared dll and does not work.

# Supplemental info (logs, images, videos)
To avoid the issue before release we create a copy of the shared library code and reference it from the one of extension project to split shared library code across extensions. Therefore we can't use automatic build.

# Test environment (full version information)
=== Visual Studio Community 2017 for Mac ===

Version 7.1 (build 1297)
Installation UUID: 65b7901d-7fe8-4ee2-b029-ab0f7c2fafce
	Mono (d15-3/da80840) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 502000215

=== NuGet ===


=== .NET Core ===

Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
SDK: /usr/local/share/dotnet/sdk/2.0.0-preview1-005977/Sdks
SDK Versions:
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/5.2.0/lib/mono/msbuild/15.0/bin/Sdks

=== Xamarin.Profiler ===

Расположение:/Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Xamarin.Android ===

Версия: (Visual Studio Community)
Android SDK: /Users/Petr_Kovalev/Library/Developer/Xamarin/android-sdk-macosx
	Поддерживаемые версии Android:
		4.1 (уровень API 16)
		7.1 (уровень API 25)

Версия инструментов SDK: 26.0.2
Версия инструментов платформы SDK: 26.0.0
Версия инструментов сборки SDK: 25.0.3

Java SDK: /usr
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

Код EPL для Android Designer доступен здесь:

=== Xamarin Inspector ===

Version: 1.2.2
Hash: b71b035
Branch: d15-1
Build date: Fri, 21 Apr 2017 17:57:12 GMT

=== Apple Developer Tools ===

Xcode 8.3.3 (12175.1)
Build 8E3004b

=== Xamarin.iOS ===

Version: (Visual Studio Community)
Hash: 4a279c9a
Branch: d15-3
Build date: 2017-08-02 12:38:11-0400

=== Xamarin.Mac ===

Version: (Visual Studio Community)

=== Build Information ===

Release ID: 701001297
Git revision: 9c5299666538b2f8baf501418a5c064d784d64da
Build date: 2017-08-07 11:29:35-04
Xamarin addins: 3bb0c32a14f1b7e368bf5ac53a84c3581c019391
Build lane: monodevelop-lion-d15-3

=== Operating System ===

Mac OS X 10.13.0
Darwin 17.0.0 Darwin Kernel Version 17.0.0
    Thu Aug 10 17:58:14 PDT 2017
    root:xnu-4570.1.43~2/RELEASE_X86_64 x86_64
Comment 1 Rolf Bjarne Kvinge [MSFT] 2017-08-18 10:19:49 UTC
Did this work for you in an earlier release, or has it always been like this?
Comment 2 Petr Kovalev 2017-08-18 11:05:04 UTC
Hello! Thanks for the fast response.

It worked the same way all the time after I initially decided to extract shared iOS extensions code into separate class library. Several previous releases of Xamarin Studio.

Comment 3 Rolf Bjarne Kvinge [MSFT] 2017-08-18 11:06:53 UTC
OK, thanks.

Just to clarify: you're not referencing this library from the main project? If not, that might in fact be a workaround.
Comment 4 Petr Kovalev 2017-08-18 11:11:18 UTC
Right, I am not referencing this library from the main project. I know that referencing may help (do not remember if tried) but one of the reasons of code extraction was intent to reduce the app size. So not a good option to include this library into the main app package.

Comment 5 Rolf Bjarne Kvinge [MSFT] 2017-08-18 13:11:19 UTC
OK, I'll have a look at this.
Comment 6 Petr Kovalev 2017-08-18 13:51:59 UTC
Thank you in advance Rolf!

Comment 7 Rolf Bjarne Kvinge [MSFT] 2017-08-21 14:32:18 UTC
I can reproduce the problem (unit test: https://github.com/rolfbjarne/xamarin-macios/commit/cf555b8aa312510ba34364479be684bb29758d6a)

I'll try to fix it for the next release (15.5).

There are at least two workarounds:

* Add '--nodevcodeshare' to the additional mtouch arguments in all projects. This will most likely cause the app size to grow.
* Reference the shared class library from the container project. This may or may not cause the app size to grow; I would try it and measure the difference.
Comment 8 Petr Kovalev 2017-08-21 15:02:15 UTC
Great news!

Interesting workarounds, going to try. And waiting for a fix!

Thank you very much, Rolf.

Comment 9 Rolf Bjarne Kvinge [MSFT] 2018-03-01 09:41:11 UTC
master: https://github.com/xamarin/xamarin-macios/pull/3626

Note You need to log in before you can comment on or make changes to this bug.