ProxyGenerationException proxying the same generic interface multiple times

[herecydev]

I've made a gist to demonstrate the ProxyGenerationException I get when trying to mock an interface with multiple observers.

The issue seems to only occur when running at least 3 observers (2 is fine strangely).

Test Outcome:   Failed
Test Duration:  0:00:00.211

Result StackTrace:  
at Castle.DynamicProxy.Generators.TypeElementCollection`1.Add(TElement item)
   at Castle.DynamicProxy.Contributors.CompositeTypeContributor.CollectElementsToProxy(IProxyGenerationHook hook, MetaType model)
   at Castle.DynamicProxy.Generators.InterfaceProxyWithoutTargetGenerator.GenerateType(String typeName, Type proxyTargetType, Type[] interfaces, INamingScope namingScope)
   at Castle.DynamicProxy.Generators.InterfaceProxyWithTargetGenerator.<>c__DisplayClass1.<GenerateCode>b__0(String n, INamingScope s)
   at Castle.DynamicProxy.Generators.BaseProxyGenerator.ObtainProxyType(CacheKey cacheKey, Func`3 factory)
   at Castle.DynamicProxy.Generators.InterfaceProxyWithTargetGenerator.GenerateCode(Type proxyTargetType, Type[] interfaces, ProxyGenerationOptions options)
   at Castle.DynamicProxy.DefaultProxyBuilder.CreateInterfaceProxyTypeWithoutTarget(Type interfaceToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options)
   at Castle.DynamicProxy.ProxyGenerator.CreateInterfaceProxyWithoutTarget(Type interfaceToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options, IInterceptor[] interceptors)
   at Moq.Proxy.CastleProxyFactory.CreateProxy(Type mockType, ICallInterceptor interceptor, Type[] interfaces, Object[] arguments)
   at Moq.Mock`1.<InitializeInstance>b__2()
   at Moq.PexProtector.Invoke(Action action)
   at Moq.Mock`1.InitializeInstance()
   at Moq.Mock`1.OnGetObject()
   at Moq.Mock`1.get_Object()

Result Message: Castle.DynamicProxy.ProxyGenerationException : Duplicate element: Castle.DynamicProxy.Generators.MetaMethod

The issue lies in this block of code @kkozmic

Currently using Moq 4.2.1502.0911

[kkozmic]

Ok, So the issue exists because of how our SwitchToExplicitImplementation works.

It does the lazy job, and doesn't really look at generic parameters of the type. Removing the check still leads to generating invalid unverifiable code so it's the naming of the method that needs to be fixed.

[jonorossi]

Fixed by pull request #285.