Bug 40565 - DependencyService fails to resolve implementation from iOS class library
Summary: DependencyService fails to resolve implementation from iOS class library
Alias: None
Product: Forms
Classification: Xamarin
Component: iOS ()
Version: 2.1.0
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2016-04-20 18:43 UTC by Anonymous
Modified: 2017-01-09 13:03 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Reproduction case (227.51 KB, application/x-zip-compressed)
2016-04-20 18:44 UTC, Anonymous

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:

Description Anonymous 2016-04-20 18:43:34 UTC
When trying to use DependencyService with an implmentation that is defined in an iOS class library, the resolution fails unless explicitly registered with the DependencyService using the Register method. Android behaves as expected. Linking is disabled, debugging is enabled, etc.

=== Xamarin Studio Enterprise ===

Version 5.10.3 (build 51)
Installation UUID: 34964b35-4cfb-4ea6-a04f-ea50483ba533
	Microsoft .NET 4.0.30319.42000
	GTK+ 2.24.23 (MS-Windows theme)
	GTK# 2.12.30

=== Xamarin.Profiler ===

Version: 0.32.0
Location: C:\Program Files (x86)\Xamarin\Profiler\XamarinProfiler.exe

=== Xamarin.Android ===

Version: (Xamarin Enterprise)
Android SDK: C:\Program Files (x86)\Android\android-sdk
	Supported Android versions:
		4.0.3 (API level 15)
		4.4   (API level 19)
		5.0   (API level 21)
		5.1   (API level 22)
		6.0   (API level 23)

SDK Tools Version: 24.4

SDK Platform Tools Version: 23.0.1

SDK Build Tools Version: 23.0.1

Java SDK: C:\Program Files (x86)\Java\jdk1.7.0_55
java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
Java HotSpot(TM) Client VM (build 24.55-b03, mixed mode, sharing)

Android Designer EPL code available here:

=== Xamarin Android Player ===

Not Installed

=== Build Information ===

Release ID: 510030051
Git revision: f3c0d982165f785772d125f02668370d929014fb
Build date: 2016-03-24 16:41:31-04
Xamarin addins: ee5cfd3ecb6b20de47c1d25efb9a9abc101e8ce7
Build lane: monodevelop-windows-cycle6-c6sr3

=== Operating System ===

Windows 6.3.9600.0 (64-bit)
Comment 1 Anonymous 2016-04-20 18:44:50 UTC
Created attachment 15787 [details]
Reproduction case
Comment 2 Paul DiPietro [MSFT] 2016-05-04 20:01:34 UTC
This is expected behavior.
Comment 3 Simon Chopin 2017-01-09 13:03:58 UTC

Having had the same problem, could you tell me where in the documentation this behaviour is hinted at?

As a side note, even if the behaviour is expected I still find it annoying for library developers (and their users) as it forces the users to add as many Register() calls in their iOS subprojects as there are dependencies, instead of having it all hidden away in the library. For the lib developer, they'll have to document this behaviour properly, *and* deal with the users who will not read said documentation.

Any chance you'd go back on the expectation?