When a DispatchProxy nested class is not public it throws TypeLoadException: Access is denied

[Mutuduxf]

The repo is here

System.TypeLoadException: Access is denied: 'DynamicProxy+InvokeProxy`1[IService]'.
   at System.Reflection.Emit.TypeBuilder.TermCreateClass(RuntimeModule module, Int32 tk, ObjectHandleOnStack type)
   at System.Reflection.Emit.TypeBuilder.CreateTypeNoLock()
   at System.Reflection.Emit.TypeBuilder.CreateTypeInfo()
   at System.Reflection.DispatchProxyGenerator.ProxyBuilder.CreateType()
   at System.Reflection.DispatchProxyGenerator.GenerateProxyType(Type baseType, Type interfaceType)
   at System.Reflection.DispatchProxyGenerator.GetProxyType(Type baseType, Type interfaceType)
   at System.Reflection.DispatchProxyGenerator.CreateProxyInstance(Type baseType, Type interfaceType)
   at System.Reflection.DispatchProxy.Create[T,TProxy]()
   at DispatchProxyDemo.DynamicProxy.Proxy[T]() in C:\Users\aeond\Desktop\GitHub\DispatchProxyDemo\DispatchProxyDemo\DynamicProxy.cs:line 9
   at DispatchProxyDemo.Program.Main(String[] args) in C:\Users\aeond\Desktop\GitHub\DispatchProxyDemo\DispatchProxyDemo\Program.cs:line 11

[EDIT] Format exception + add exception line by @karelz

[karelz]

Simplified repro - it repros on .NET Core 2.0. I wonder if it is by design.

using System.Reflection;

public class DynamicProxy
{
    public static T Proxy<T>() => DispatchProxy.Create<T, InvokeProxy<T>>();

    // If the access modifier is private/protected/internal it will throw the exception unless public.
    private class InvokeProxy<T> : DispatchProxy
    {
        protected override object Invoke(MethodInfo targetMethod, object[] args) => null;
    }
}

public interface IService { }

class Program
{
    static void Main()
    {
        DynamicProxy.Proxy<IService>();
    }
}

[joshfree]

Reference to old bug on this : https://github.com/dotnet/corefx/issues/11494

Seems like a limitation imposed by the fact that we're using refemit to generate a call to InvokeProxy rather than a limitation that we'd want to impose no matter what. It's unlikely to be feasible in the 2.1 timeframe - if there's sufficient demand, we can investigate if there are ways to lift this limitation in the future.

[ggeurts]

I just ran into the same issue this week.

[ElderJames]

I have this issue too.

@joshfree any chance we could get DispatchProxy its own owner? This feature has nothing to do with Reflection - it just got thrown into the Sytem.Reflection namespace for some reason.

[joshfree]

@atsushikan @steveharter I'm inclined to keep it clumped with the rest of Reflection.* for the time being, unless the incoming rate spikes significantly. Let's get this particular bug fixed for the 3.0 release.

[steveharter]

Proposing to move the to future.

[ltrzesniewski]

Here's a workaround for internal types;

[assembly: InternalsVisibleTo("ProxyBuilder")]

This will fail if the implementation ever changes the ProxyBuilder assembly name.