1

I've been reading about how ASP.NET Web API looks up the locations of controllers in assemblies, and ways to dynamically add a new assembly to look in. So far this has all been fine, except I've noticed a few random references to how the controller cache will ignore loading any controller that lives in a dynamic assembly (.IsDynamic == true), and some workarounds to force it to work with a dynamic assembly.

However, I can't find any documentation as to the why. Is this just an implementation decision by the ASP.NET team, or is there something more fundamental about this that having a dynamically generated assembly would cause real trouble or breaking something?

Any insights or links to docs that could shed some light on this? I have some guesses, but I'm curious to know the real reasons.

I want to be completely clear that I'm not having trouble making any of this work, I'm wondering why this design route was taken and what caveats accompany it.

Links:

https://www.strathweb.com/2013/08/customizing-controller-discovery-in-asp-net-web-api/ - specifically references a way to work with dynamic assemblies and that they would be ignored otherwise

https://stackoverflow.com/questions/28567070/simple-injector-container-fails-to-register-web-api-controller-from-pluggedin-ex - a SO question that lists making sure the assembly is not dynamic in troubleshooting steps.

Improve this question
  • Can you provide links to those "random references?" – Robert Harvey Jul 16 '18 at 17:01
  • @RobertHarvey I didn't include the "random links" at first because I assumed ignoring dynamic assemblies was somewhat common knowledge, but not necessarily the reason why. – cost Jul 16 '18 at 17:12
5

This problem originates in the .NET Framework itself, not in ASP.NET Web API.

If you look at the code for DefaultHttpControllerTypeResolver.cs line 80, you'll see that it contains the following comment:

// can't call GetExportedTypes on a dynamic assembly

Looking up Assembly.GetExportedTypes() Method, it throws NotSupportedException with the description "The assembly is a dynamic assembly."

There are several methods in Reflection that don't work on dynamic assemblies, including AppDomain.CurrentDomain.GetAssemblies() and Assembly.Load(). I suspect this is a security issue; dynamic assemblies cannot be code-signed or afforded any of the usual security protections, and should therefore not be run in full trust, if that's even possible.

Further Reading
Security Issues in Reflection Emit

Improve this answer
  • Thanks! This is exactly the kind of insight I was hoping for. I was unaware dynamic assemblies had those restrictions, but that makes sense. I'll do some further reading in that area. – cost Jul 16 '18 at 17:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.