> A debug compile against the same types marked public (instead of internal) works fine.
> A non-debug compile against the internal types works fine.
> Did I miss a flipped bit somewhere? Is this a supported scenario? I've got lots of internal types that I
want to execute in DLR but not expose to the world at large...
Running expression trees against internal types is tricky. CLR security will generally prevent it from working. If the code is running in a DynamicMethod,
it can work thanks to a special CLR feature (skipVisibility), as long as your application has the right permissions. However, if the code is emitted into a dynamic assembly using a TypeBuilder, it can’t refer to a non-public type in another assembly (which
your language’s assembly affectively is).
I’m not 100% sure why it would work in release but not debug. My guess is it works in release mode because we’re generate DynamicMethods, whereas in debug
mode we’re trying to save the code into Snippets so we can run peverify against it.
I would not recommend emitting ETs that use non-public types/methods, and instead make them public. If you’re worried about users seeing them, you could
put them in some class/namespace that’s marked as internal use only. Unfortunately that’s the closest thing we currently support.