Remove custom IoC implementation

[janschmidmaier50]

Right now there is a custom implementation wrapping the default Microsoft one, extending it to use named registrations.

Imho there are enough IoC frameworks out there, providing every usecase that we need, even it is a such a thing like named registrations. Using other frameworks, it should also be way easier to use the decorator pattern or auto-factory injection. For example Autofac which is providing this, is a (from my point of view) great implementation. Features I am missing right now are for example

• auto factories
• decorator pattern
• modules / registries
• register of not registered yet

Concerns

We want to onboard new developers as quickly as possible plus letting them work as efficient as possible. Many developers know the major IoC frameworks and there are lots of articles / tutorials / stackoverflow articles out there. So if someone runs into a problem, chances that somebody else had that problem already with a public (well-known) IoC implementation are not too bad. Understanding, that with the Arc4u implementation one needs to add the ExportAttribute in order to be able to registered that via the Arc4u way of registering plus the RegistryConfiguration is not obvious at all. Which makes it even worse is that the Arc4u ExportAttribute has the same name as the Microsoft one, but a completely different meaning.

Compare: System.ComponentModel.Composition.ExportAttribute: Register the class for IoC Arc4u.Dependency.Attribute.ExportAttribute: Make this class available for the Arc4u IoC registration

Right now there are different ways to do registrations when using the Arc4U:

• Use the Application.Dependency:Assemblies configuration plus the ExportAttribute
• Use the Application.Dependency:RegisterType configuration plus the ExportAttribute

Another concern is that right now, registrations are spread over multiple places, e.g.

• the two appsettings blocks (plus think of stage depended configurations)
• via default .net registration like AddSingleton, for exmple when you use decorators
• via Microsoft's ExportAttribute

[GFlisch]

Indeed but the choice was done to use most of the time the .NET framework components. The problem with Autifac is its performance. DryIoc could be an option. We are evaluating this.

Method	Mean	Error	StdDev	Ratio	RatioSD	Gen 0	Gen 1	Gen 2	Allocated
DryIoc	82.22 us	1.209 us	1.072 us	1.00	0.00	6.3477	0.3662	-	39.42 KB
DryIoc_MsDI	94.18 us	1.207 us	1.070 us	1.15	0.02	8.0566	0.6104	-	49.87 KB
MsDI	94.60 us	0.715 us	0.597 us	1.15	0.01	11.8408	4.2725	-	72.59 KB
Autofac	543.45 us	4.570 us	3.568 us	6.60	0.10	51.7578	25.3906	1.9531	317.19 KB
Autofac_MsDI	534.64 us	5.919 us	5.247 us	6.50	0.10	54.6875	27.3438	1.9531	340.17 KB
Lamar_MsDI	7,053.46 us	140.273 us	402.469 us	77.97	2.84	-	-	-	649.68 KB
Grace	15,990.58 us	123.798 us	109.744 us	194.52	2.21	93.7500	31.2500	-	736.12 KB
Grace_MsDI	18,884.30 us	321.388 us	268.373 us	229.50	4.25	125.0000	62.5000	-	904.7 KB

[maxime-poulain]

@GFlisch is right AutoFact has horrible performance. Daniel Palme has made comparison of many many many IoC performance. Can be see there (don't pay attention to the 2011 in the URL that article get updated frequently ...).

AutoFac (and NInject btw) are even so bad they cannot fit in the diagrams as they are super slow. . .

Regardless, to me using attributes to configure you DI is per se a bad practice. I strongly recommend not using that but fluent configuration file as you can depending on configurations, environment, etc do specific kind of logic.

@GFlisch I have been using DryIoc for every project in Xamarin or WPF it does work well. Brian Lagunas, author of PRISM, decided in 2017 or so to switch from Unity to DryIoc that's not for nothing.