System.Reflection.DispatchProxy inconsistently fails for internal interfaces

[AArnott]

An undocumented limitation in DispatchProxy.Create is that it sometimes throws for various configurations of visibility. This seems to be a broader issue than the more specific #25595.

These configurations work:

1. public interface, public base class.
2. internal interface, internal base class, within the same assembly. But only when this is the first proxy ever generated.

These configurations don't work:

1. public interface, internal base class.
2. internal interface, internal base class, if another assembly has already provided an internal interface to generate a proxy for.

There were other odd configurations that similarly failed.

Since I've done this kind of feature before, I have a suspicion that the generated ProxyBuilder assembly includes an System.Runtime.CompilerServices.IgnoresAccessChecksToAttribute for the assembly that defines the interface.
The way I solved this is that each time I need to generate a proxy, I evaluate all the assemblies that visibility checks must be skipped for and create a new dynamic assembly for each unique set that I get. So multiple proxies are supported, and we reuse dynamic assemblies where possible but when the set of dynamic assemblies exceed any previously discovered set we have to start a new assembly.

Adding more attributes to an existing dynamic assembly is ineffective because once you've loaded the first type from the assembly, the CLR caches these attributes and doesn't notice when new ones are added.

[ltrzesniewski]

Note that you can use an internal base class if you add this attribute to its assembly:

[assembly: InternalsVisibleTo("ProxyBuilder")]

That's undocumented though.

[AArnott]

That wouldn't fix it for private types--only internal ones.

[AArnott]

It also wouldn't work from a strong-name signed assembly, since those are required to only use IVT attributes with other strong-name signed assemblies.

[steveharter]

Is this blocking certain scenarios, and are there workarounds? Trying to determine priority.

Do we need to emit into a specified assembly?

[AArnott]

It's blocking our use of this type.
Instead we resort to writing our own ref.emit code to dynamically generate proxies. Not a trivial task, but I've done it a few times before.
It may be possible to replace some of our custom proxy generators with this class once this issue is fixed.

[GrabYourPitchforks]

What configurations specifically are you looking to be supported? The public interface on an internal base class?

The reason for our questions is that we have a boatload of other reflection work planned for 5.0, and we're trying to figure out prioritization for everything. If this is moved above the cut line something else has to fall below the cut line. But maybe we can identify some small, self-contained nugget of work that wouldn't fix the problem for the general case, but which would make your scenario work. :)

[AArnott]

We would need both configurations that are broken as listed in the issue description to work in order to switch to this class.

FWIW I think you can prioritize this fairly low on your .NET 5 backlog. We've already completed our workaround and aren't likely to spend time switching to DispatchProxy even if you did fix it before .NET 5 anyway.