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 ...
Status: RESOLVED FIXED
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]
URL:
Depends on:
Blocks:
 
Reported: 2017-08-18 08:41 UTC by Petr Kovalev
Modified: 2018-03-02 08:43 UTC (History)
4 users (show)

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

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

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
Runtime:
	Mono 5.2.0.215 (d15-3/da80840) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 502000215

=== NuGet ===

Версия: 4.3.0.2418

=== .NET Core ===

Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
	2.0.0-preview1-002111-00
	1.1.1
	1.1.0
	1.0.4
	1.0.3
SDK: /usr/local/share/dotnet/sdk/2.0.0-preview1-005977/Sdks
SDK Versions:
	2.0.0-preview1-005977
	1.0.3
	1.0.0-rc4-004583
	1.0.0-preview2-1-003177
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/5.2.0/lib/mono/msbuild/15.0/bin/Sdks

=== Xamarin.Profiler ===

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

=== Xamarin.Android ===

Версия:7.4.0.19 (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 доступен здесь:
https://github.com/xamarin/AndroidDesigner.EPL

=== 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: 10.12.0.18 (Visual Studio Community)
Hash: 4a279c9a
Branch: d15-3
Build date: 2017-08-02 12:38:11-0400

=== Xamarin.Mac ===

Version: 3.6.0.17 (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.

Petr.
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.

Petr.
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!

Petr.
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.

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