I'm not sure what you're dynamic execution scenario is, but the class is pretty flexible in allowing you to run just about anything. The library allows for adding namespacing and library references. Assuming you add the appropriate libraries to your Bin directory you can load just about any code so there are very few limitations on what you can actually execute.

I think the typical use case scenario is to allow the dynamic code to implement a set of interfaces that provide the functionality profile of what's allowed in terms of functionality.

Reflection is slow mainly for lookups and first time compilation of code, but it's pretty fast for actual object member invocation so as long as objects are cached and even better if fixed interfaces are used execution of this code can quite fast as well.

+++ Rick ---

>We were able to get this to work, but Reflection isn't very compatible with NET app protection and we ran into grief because the calling app needs to know quite a lot about the code you're about to run so it can cast and send/receive the correct values, so complexity seems to rise logarithmically with flexibility.
>
>E.g. if you want dynamic code to optionally act on one of several resultsets or perform customer-specific manipulations, won't you need to pass multiple extraneous parameters to your generic routine every time to be sure the dynamic code gets what it needs, and then process an equally complex set of results to allow for every potential action? There's also the issue of dependencies if the code truly can be dynamic.
>
>Obviously all this will be OK if the dynamic code has a relatively limited set of actions and possibly we misunderstood anyway, in which case I'd be keen to revisit.