{"id":2539,"date":"2018-10-17T23:16:05","date_gmt":"2018-10-18T03:16:05","guid":{"rendered":"https:\/\/ikriv.com\/blog\/?p=2539"},"modified":"2018-10-17T23:16:05","modified_gmt":"2018-10-18T03:16:05","slug":"stack-overflow-in-unity-di-container-when-registering-a-decorator","status":"publish","type":"post","link":"https:\/\/ikriv.com\/blog\/?p=2539","title":{"rendered":"Stack overflow in Unity DI Container when registering a Decorator"},"content":{"rendered":"

After upgrading to a newer version of Unity, we found that our process began to fail with StackOverflowException<\/code>. Investigation showed that it happened because the following registration behaves differently depending on the version of Unity:<\/p>\n

container.RegisterType<TInterface, TType>(new InjectionFactory(...));<\/code><\/p>\n

Github project ikriv\/UnityDecoratorBug<\/a> explores the behavior for different versions. Strictly speaking, the registration is self-contradictory: it may mean either<\/p>\n

\/\/ (1) Resolve TInterface to whatever is returned by the InjectionFactory<\/span>
\ncontainer.RegisterType<TInterface>(new InjectionFactory(...));<\/code><\/p>\n

or<\/p>\n

\/\/ (2) Resolve TInterface to container-built instance of TType<\/span>
\ncontainer.RegisterType<TInterface, TType>();<\/code><\/p>\n

Early versions of Unity ignored the TType part and used interpretation #1. In the release notes for version 5.2.1<\/a> it was declared that such registrations are no longer allowed, but in reality they were silently interpreted as (2), ignoring the InjectionFactory part.<\/p>\n

This led to a catastrophic problem in our code. We had a decorator type similar to this:<\/p>\n

public class Decorator : IService\r\n{\r\n    public Decorator(IService service) {...}\r\n}<\/pre>\n
and the registration declaration was<\/p>\n
container.RegisterType<IService, Decorator>(
\nnew InjectionFactory(c => new Decorator(c.Resolve<ConcreteService>())));<\/code><\/p>\n
If the injection factory is ignored, this leads to an infinite recursion when resolving IService<\/code>: IService<\/code>\u00a0is resolved to\u00a0Decorator<\/code>, that accepts\u00a0IService<\/code> as a parameter, that is resolved to\u00a0Decorator<\/code>, that needs IService<\/code> as a paramter, that is resolved to Decorator<\/code>…<\/p>\n
In Unity version 5.7.0 this was fixed and such registrations throw an InvalidOperationException<\/code>.<\/p>\n
To recap:<\/p>\n\n\n\n\n\n\n
Unity version<\/th>\nEffect of the registration<\/th>\n<\/tr>\n
<=5.2.0<\/td>\nInjection factory used<\/td>\n<\/tr>\n
5.2.1 to 5.6.1<\/td>\nInjection factory ignored, StackOverflowException for decorators<\/td>\n<\/tr>\n
>=5.7.0<\/td>\nInvalidOperationException<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Lessons learnt:<\/p>\n