ASP.NET MVC 3 RC AreaRegistration.RegisterAllAreas() and dynamically loaded assemblies

Question

I am currently experimenting with dynamically loaded areas with ASP.NET MVC 3 RC. I\'ve seen it written in many places that this is not what areas are intended for, and (at

Answer 1

The way things work is a bit complicated.

GetReferencedAssemblies includes referenced assemblies, not loaded assemblies. This includes:

• all assemblies referenced in you application's web.config (such as System.Web.Mvc)
• everything inherited from root web.config, which includes things like System, System.Web and others that you do not have to add yourself. (You can take a look at the list here: C:\Windows\Microsoft.Net\Framework\v4.0.30319\web.config).
  It also contains a special * item, which:
• includes everything in your site's bin folder

So now take your app v1 (everything in a single app). Everything works because the application code gets compiled into the bin folder which gets automatically included. Also, all of the area views etc are in the application itself so they are accessible.

Now in app v2 (different project with a proj-to-proj reference and a custom build task that copies the views to the right location in your main app) everything still works, because by default a proj-to-proj references means that the class library binary gets copied to your app's bin folder. So by the above rules, the area code still gets loaded correctly. The fact that you've set the library's output path to be some location within your main app's Areas folder does not actually make a difference - you just end up with two copies of the binary.

Now in app v3 (no proj-proj ref, area library assembly loaded manually) your library assembly gets loaded too late. By the time your code runs the set of referenced assemblies has already been locked and can no longer be changed.

There is a way to run code and add items to the list of registered assemblies: you can do it using the AddReferencedAssembly method which must be invoked from a PreApplicationStartMethodAttribute method.

Of course you still have to deal with how you manage your view files. The way you currently have it set up is pretty much the same as having the views in the main application (since they effectively get copied into the right location).