[Bug] DependencyService fails to return existing instances in some situations

[Tommigun1980]

Description

Let's say you have a service such as:

public interface ISomeInterface : ISomeOtherInterface
{
}

public interface ISomeOtherInterface
{
}

public class SomeService : ISomeInterface
{
}

You register it with XF's DI system:

DependencyService.Register<SomeService>();

You fetch an instance of ISomeInterface:

var instance = DependencyService.Get<ISomeInterface>();

This creates an instance of 'SomeService', and the type of the instance is 'SomeService'. This is correct.

You now fetch an instance of ISomeOtherInterface:

var instance2 = DependencyService.Get<ISomeOtherInterface>();

The type of instance2 is 'SomeService', this is correct.
HOWEVER! PROBLEM: The DI system creates a new instance instead of returning the already existing instance.

So:

instance.GetType() == instance2.GetType(); // true. Correct.
instance == instance2; // false. INCORRECT!

Expected Behavior

The existing instance should be returned in the above case.

Actual Behavior

The DI system creates a new global instance and returns it instead.

This is very dangerous as you will end up with different instances (of the same type) from the DI container depending on how you fetch them. This goes against the point with a DI system, and is so easy to miss as it looks like you are working with a single instance (which it should be with the 'Global' scope) but in reality the DI system returns multiple instances.

Basic Information

• Version with issue: 5.0.0.2012
• Last known good version: None
• Platform Target Frameworks:
  • iOS: 14.5

Environment

Show/Hide Visual Studio info

=== Visual Studio Community 2019 for Mac ===

Version 8.10.1 (build 71)
Installation UUID: bb9df785-aacc-4308-b127-e1586a7bc445
	GTK+ 2.24.23 (Raleigh theme)
	Xamarin.Mac 6.18.0.23 (d16-6 / 088c73638)

	Package version: 612000140

=== Mono Framework MDK ===

Runtime:
	Mono 6.12.0.140 (2020-02/51d876a041e) (64-bit)
	Package version: 612000140

=== Roslyn (Language Service) ===

3.10.0-4.21269.26+029847714208ebe49668667c60ea5b0a294e0fcb

=== NuGet ===

Version: 5.9.0.7134

=== .NET Core SDK ===

SDK: /usr/local/share/dotnet/sdk/5.0.301/Sdks
SDK Versions:
	5.0.301
	5.0.203
	5.0.202
	3.1.410
	3.1.409
	3.1.408
MSBuild SDKs: /Applications/Visual Studio.app/Contents/Resources/lib/monodevelop/bin/MSBuild/Current/bin/Sdks

=== .NET Core Runtime ===

Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
	5.0.7
	5.0.6
	5.0.5
	3.1.16
	3.1.15
	3.1.14

=== .NET Core 3.1 SDK ===

SDK: 3.1.410

=== Xamarin.Profiler ===

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

=== Updater ===

Version: 11

=== Apple Developer Tools ===

Xcode 12.5 (18205)
Build 12E262

=== Xamarin.Mac ===

Xamarin.Mac not installed. Can't find /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/Version.

=== Xamarin.iOS ===

Version: 14.20.0.3 (Visual Studio Community)
Hash: 17fdcf569
Branch: d16-10
Build date: 2021-05-20 15:46:15-0400

=== Xamarin Designer ===

Version: 16.10.0.119
Hash: 36a2d986f
Branch: remotes/origin/d16-10
Build date: 2021-06-02 19:41:34 UTC

=== Xamarin.Android ===

Version: 11.3.0.1 (Visual Studio Community)
Commit: xamarin-android/d16-10/22fc2b3
Android SDK: /Users/tommikiviniemi/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		None installed

SDK Tools Version: 26.1.1
SDK Platform Tools Version: 30.0.4
SDK Build Tools Version: 30.0.2

Build Information: 
Mono: b4a3858
Java.Interop: xamarin/java.interop/d16-10@f39db25
ProGuard: Guardsquare/proguard/v7.0.1@912d149
SQLite: xamarin/sqlite/3.35.4@85460d3
Xamarin.Android Tools: xamarin/xamarin-android-tools/d16-10@c5732a0

=== Microsoft OpenJDK for Mobile ===

Java SDK: /Users/tommikiviniemi/Library/Developer/Xamarin/jdk/microsoft_dist_openjdk_1.8.0.25
1.8.0-25
Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

=== Android SDK Manager ===

Version: 16.10.0.12
Hash: e240b8c
Branch: remotes/origin/d16-10
Build date: 2021-06-01 18:26:34 UTC

=== Android Device Manager ===

Version: 16.10.0.14
Hash: e340248
Branch: remotes/origin/d16-10
Build date: 2021-06-01 18:26:52 UTC

=== Build Information ===

Release ID: 810010071
Git revision: 3664adb3ec17b7a29476110bb1c6f7083d43b1ab
Build date: 2021-06-08 13:22:15-04
Build branch: release-8.10

=== Operating System ===

Mac OS X 10.16.0
Darwin 20.5.0 Darwin Kernel Version 20.5.0
    Sat May  8 05:10:33 PDT 2021
    root:xnu-7195.121.3~9/RELEASE_X86_64 x86_64

[bondarenkod]

That's an expected behavior by default. Most of IoC containers works in the same way until you command them to register a type as singleton.
The built-in DependencyService contains only the necessary logic to handle XF needs itself.

BTW you can try to use DependencyService.RegisterSingleton method.
There are many other containers that can fulfill your needs like Unity, DryIoC and many others if you are not satisfied with the built-in one.

[Tommigun1980]

That's an expected behavior by default. Most of IoC containers works in the same way until you command them to register a type as singleton.
The built-in DependencyService contains only the necessary logic to handle XF needs itself.

BTW you can try to use DependencyService.RegisterSingleton method.
There are many other containers that can fulfill your needs like Unity, DryIoC and many others if you are not satisfied with the built-in one.

There must be a misunderstanding here. The above example is operating on singletons only; this is not about scoped services.

In the above example you get two different singleton instances (of the same class) depending on how you request for the instance. This is wrong.

The DI system correctly pairs the requested interfaces to the implementing class, but it fails at retrieving an already created instance unless the requested interface exactly matches the one with which it was requested before. It should apply the same logic to determine which registered class an interface belongs to and return that instance, not a new one.

DependencyService.RegisterSingleton is not relevant here as it merely allows you to register an already created instance. DependencyService.Register registers a type for the DI system to return and it also operates only on singletons, as the XF DI system is quite limited. I can take limited (and have extended it myself via packages such as https://github.com/Tommigun1980/Xamarin.Forms.MultiDependencyResolver), but I can't take incorrectly working as it breaks things.