Invalidate type cache for proxies based on dynamic types?

[bclothier]

I'm using DynamicProxy indirectly via Moq and I'm running into a problem. AIUI, DynamicProxy maintains a cache of types that were generated. As long the types don't change, this is OK. However, in my scenario, I'm dealing with types that do get changed in runtime, and as a consequence, subsequent invocation of the mocks based on those types fails with exceptions like MissingMethodException or such.

Is there a way to ensure that certain types will never be cached or effect an invalidation of the types?

[stakx]

I am not aware of a way to completely turn off the proxy type cache.

As I mentioned in Moq's Gitter chat, one easy way to effectively circumvent the proxy type cache is by instantiating a new ProxyGenerator for each proxy. That way, you get one type cache per proxy that will never get queried. You'll also get one dynamic assembly per proxy. It's rather wasteful, and we usually advise against using DynamicProxy that way.

Also, since you're not using DynamicProxy directly but through a mocking library (Moq), the creation of ProxyGenerators might not be under your control. In fact, Moq uses a single ProxyGenerator for all its mocks.

Another possibility that I mentioned is to reuse a ProxyGenerator, but add a unique empty interface to your proxies / mocks to ensure that you'll never get a cache hit. Moq allows this via mock.As<TInterface>() but you might have to use Reflection.Emit to create unique interfaces on demand. You could also have a smallish number of predefined empty interfaces that you add to your proxies in unique combinations. n interfaces would suffice to create 2ⁿ combinations.

Perhaps more importantly, I'd be interested to learn a little more about the background. How come that the types you're mocking change at runtime?

[bclothier]

This is for developing a mocking framework in VBA, wrapping around Moq (and subsequently DynamicProxy which Moq uses). The VBA types (as well as COM types) are created into a System.Type via Type.GetTypeFromProgId or Marshal.GetTypeForITypeInfo.

I have observed that once we have mocked one VBA type, if the user then proceed to make changes to the VBA type (e.g. changing a signature of the method or adding a method), then re-run the tests with the mocks, we generate a new type via the Marshal.GetTypeFrorITypeInfo, but then we get exceptions about missing methods in the mock, due to the proxy generator having had cached that type from previous mocking invocation.

In this scenario, only the VBA types needs to be considered volatile because the users can change it at the runtime (from the POV of the add-in & Moq, even though from VBA's POV, it's not runtime because the users is editing code between the invocations of VBA, but the addin is still loaded the meanwhile).

I hope that help explains the background.

[stakx]

If I understand correctly, we are talking about some kind of Edit-and-Continue scenario?

[bclothier]

No, that's not applicable in this scenario. I'm not talking about editing the VBA code in a break mode. I'm talking about editing the VBA code in between the executions. The problem is simply that the add-in is always loaded at all the times, so when we run VBA code Nth time, the proxy generator cache still remembers the types from previous runs.

[stakx]

I see. If there is no way to unload & reload your add-in, and proxy type caching causes you problems, then I suspect using a single ProxyGenerator for a whole session (say, by following my second suggestion above) would essentially introduce a memory leak as new types would keep getting emitted into DP's dynamic assembly—regardless of whether there's additionally a type cache layer or not, you can't partially GC types from a dynamic assembly.

I fear that you'll have to use a fresh ProxyGenerator at least every time a new VBA code execution begins. In that case, I believe we can close this issue as DynamicProxy can already do what you need it to do; the problem lies further up in your stack, i.e. with Moq.

My understanding of your setup might still be imperfect, let me know if the above thoughts and conclusions resonate with you.

[bclothier]

I agree. For context, I opened the issue before I knew about Moq's proxy generator behavior. Now I know that by creating a new proxy generator, we can avoid the issue, so yes I agree that this is further up the stack. Should I open an issue on Moq anyway?

[stakx]

Sure. I might have an idea or two.