R – ASP.NET MVC 2 Preview 1 – what is the best way to implement areas

I've found a solution. I don't think it is appropriate, so I will ask for an improvement. By specifying a controller name, I can get the URL to form properly. I.E.

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">

<h2>Index</h2>

<%= Html.ActionLink("Foo Index Page", "Index", new { area="Foo", controller="Baz" } )%>

</asp:Content>

Once I did this, then the URL was correct

localhost:6494/Foo

Why is this a problem? Phil's demo uses the controller with the name HomeController. I don't know (because I can't trace) how the Html.ActionLink() method goes about constructing the URL; but it looks as if it is relying on a default case of HomeController existing, which I don't have.

If anyone has a suggestion on how to allow for Controllers not named Home to be the default, please reply. Thanks

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).