proxying generic interface with inaccessible type parameters throws TypeLoadException

[blairconrad]

Consider this test:

internal interface InternalInterface
{
}

[Test]
public void CreateClassProxyType_PublicInterfaceWithInternalTypeParameter_ThrowsTypeLoadException()
{

    new DefaultProxyBuilder()
        .CreateClassProxyType(typeof (object),
                              new[] {typeof (IList<InternalInterface>)},
                              new ProxyGenerationOptions());
}

It results in the following error:

CreateClassProxyType_PublicInterfaceWithInternalTypeParameter_ThrowsGeneratorException : FailedSystem.TypeLoadException : Type 'Castle.Proxies.ObjectProxy' from assembly 'DynamicProxyGenAssembly2, Version=0.0.0.0, Culture=neutral, PublicKeyToken=a621a9e7e5c32e69' is attempting to implement an inaccessible interface.
at System.Reflection.Emit.TypeBuilder.TermCreateClass(RuntimeModule module, Int32 tk, ObjectHandleOnStack type)
at System.Reflection.Emit.TypeBuilder.CreateTypeNoLock()
at System.Reflection.Emit.TypeBuilder.CreateType()
at Castle.DynamicProxy.Generators.Emitters.AbstractTypeEmitter.CreateType(TypeBuilder type)
at Castle.DynamicProxy.Generators.Emitters.AbstractTypeEmitter.BuildType()
at Castle.DynamicProxy.Generators.ClassProxyGenerator.GenerateType(String name, Type[] interfaces, INamingScope namingScope)
at Castle.DynamicProxy.Generators.BaseProxyGenerator.ObtainProxyType(CacheKey cacheKey, Func`3 factory)
at CastleInaccessibleInterface.Tests.CreateClassProxyType_PublicInterfaceWithInternalTypeParameter_ThrowsGeneratorException() in Class1.cs: line 26

A novice user (or indeed someone indirectly using DynamicProxy, for example, via an isolation framework such as FakeItEasy or Moq), may be confused by this error message.

DynamicProxy goes to good lengths to intercept attempts to proxy what I'll call top-level types that aren't accessible (for example, if we were proxying InternalInterface directly, rather than an IList of them). Is there any interest in expanding the "bad request" detection to include inaccessible type parameters?

If so, I'd be happy to spend some time on it.

[kkozmic]

Hi,

sorry for getting back to you so late. I think it would be worthwhile to give a better message here. Especially that, as you noted, it is currently quite confusing.

[blairconrad]

No worries about the delay. I can start working on a fix. Is there a timeline? I'm not going on vacation like last time...

[kkozmic]

timeline?

for a release? It's quite fluid :) It's probably better to get a fix sooner rather than later, but the way it's been going we're going to do a release either if there is a major bug fixed (like with v3.2.2) or when we accumulate several smaller fixes (like with v3.2.1

[blairconrad]

Okay, thanks. Based on my interpretation of your comments on the urgency of getting this in, I will make this issue my next Open Source work item, but will not allow it to endanger the on time delivery of my grandmother's Christmas present. ;-)

[kkozmic]

That sounds reasonable.

BTW, in the long run, the best solution would be to finish the work on generic proxies I spiked in v4 branch (https://github.com/castleproject/Core/tree/4.0-unstable) which would end up, generating FooProxy<T> rather than FooListOfInternalInterfaceProxy but this is a major rewrite of the codebase, so I don't know when it's going to be completed.

Anyway,

Merry Christmas

[adamralph]

Is it yet known when this will be released?