Develop Reference

Split controllers into 2 separate DLLs

I have an idea I'd like to implement which basically involves separating the controllers in an MVC4 Project to 2 different projects. The reason being I'd like to be able to have different controllers for an internal admin section of my site and for the external client section. I'd like to make changes to each of them individually and add a new DLL to the website as I make changes...the changes to the internal admin section of the site thus not affecting the controllers DLL for the external client section for example.
Does anyone know if this is possible/advisable or of a better way to accomplish what I'm trying to achieve?

taken from an artical :
"The MVC framework provides a default controller factory (aptly named DefaultControllerFactory) that will search through all the assemblies in an appdomain looking for all types that implement IController and whose name ends with "Controller." Thus, if you tell the factory to look for a "Home" controller, the factory can return a newly instantiated instance of a HomeController class regardless of the namespace or assembly it lives in—as long as it implements IController...."
by adding a reference to another project in you'r solution you can achieve what you are looking for, in that referenced project add you'r controllers. like written above the MVC Routing will find all controllers that been referenced in that solution.

Curious about MVC Controllers?

Just a quick question, when you create a new controller for a new MVC ASP.Net app how does it know which controller to use. More specifically, given you create a new controller and you call it SockController in order to use said controller I would navigate to http://mywebapp/sock. How did the web app know that /Sock/ is linked to SockController? Is there a mapping somewhere ? Or if not what happens when if you call omit controller from the name when creating it, ie call it SockCont.
Note: I am not a Web Dev im just curious so please don't post links to page with tons of text, im looking for a short simple answer.

ASP.NET Routing extracts the name of the controller from the URL by getting the Route Value and then appending "Controller" to the end. So "/home/" returns "HomeController".
ASP.NET then uses reflection to go through every class in the project's assembly (or referenced assemblies) to find a class that inherits from System.Web.Mvc.Controller and is called "HomeController". It then uses the default, parameterless constructor to create an instance of it.
It then matches the Route action to a method of the controller.
This process is called "Dispatch" and similar patterns are seen in PHP, Ruby-on-Rails, etc, except that dynamic languages like those have different ways of resolving class names to actual objects (CakePHP uses Class auto-loading bindings to locate the class definition, for example).

Can MVC Views access all projects even though they aren't referenced by the project where the views are?

Ok, so I'm a bit confused as to what is going on with the following data.
We have the following Structure in our application:
Portal.Web - An MVC 3 Web App which basically contains all the
views, scripts, css and HTML helper extension methods
Portal.Core - A Class Library which is basically our Business Objects, we have all of our models contained within this project.
Portal.Data - Another Class Library which contains our NHibernate config and our DTO classes.
Here's our usage: In the controller we call the model located in Portal.Core, which populates by calling Portal.Data, so basically Web can never see data.
Here's the catch: In the controller, say for example I try and instantiate a new DTO object called Client like so:
var client = new Client();
It won't work, which is expected it has no idea what Client is and even specifying a using won't cut it. That's fine.
BUT if I try and do that exact same line in the View, Resharper adds the using to the view and then no complaints, the project runs and we can use DTO classes in our views.
So the question is, why is this? I'm trying to stop our juniors from using DTO classes in Views, so I've purposely removed the reference to the Data project in Web, but they can still use the classes. Can someone shed some light?

I ran the same test with ASPX and Razor views. Referencing Client in ASPX views fails however in Razor views they work. The views are compiled on the fly when you request the application, so I had a look at some folders in "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\portal.web" and from cmdline files references to the assembly is explicitly added when the view is compiled.
It seems the process that compiles razor views adds references to all the assemblies in the bin folder. However, looking at the source of ASP.NET MVC, I cannot confirm this.
So, the only conclusion I can come to is that it is a side effect of using the Razor View Engine.
That said, you may want to scan the web.config to see if it was included using the assemblies element.

Change the Location of the Controller inside the Project structure

I found this Post (How to extend where MVC looks for views) about changing the location of the View.
I was wondering if there's something similar for changing the location of the controller.
I just want to change the location of the class inside project and don't want to affect the url.
For example Instead of placing the Controller into
MyMvcProject\Controllers\
MyController1.cs
MyController2.cs
MyController3.cs
I want to achieve something like
MyMvcProject\MyGroup1\
MyController1.cs
MyController2.cs
MyMvcProject\MyGroup2\
MyController3.cs
and also support Areas:
MyMvcProject\Areas\MyGroup3\
MyController4.cs
Is it possible to achieve this? And if yes, where can I find documentation about it?

You can do what you want, and it doesn't require any special configuration, because ASP.NET MVC does not care about where you put your controllers. First, controllers are located using reflection, so the name of the folder where you put your controllers is irrelevant. Controllers are searched by type name and optionally by namespace (for disambiguation). You can even have controllers in separate projects/assemblies. As long as the controller ends up in an assembly in the bin folder then it's searchable by the framework.

As mentioned above, you'll need to create a controller factory to support your custom resolution. Here's an example:
http://develoq.net/2010/custom-controller-factory-in-asp-net-mvc/

As others have already stated you need to do one of the following:
Derive from IControllerFactory interface and provide an implementation of the CreateController and ReleaseController methods.
Derive from DefaultControllerFactory and override the default behaviours.
Here are some links to get you started:
Custom controller factory in ASP.Net
Inside the ASP.NET MVC Controller factory
Dive deep into MVC - IControllerFactory
Also, if you're willing to spend a bit of money I would also recommend the book Pro ASP.NET MVC 3 Framework as this explains almost every aspect of how the MVC framework can be customised (including an example on how to create a custom controller factory - the source code for which can be freely downloaded from the publishers website).

I think it is impossible to do this. ASP.NET MVC have defined the convention that we have to follow.
Controllers are in Controllers folder, views are in Views{ControllerName}\

I believe you cannot change the convention unless you create your own ControllerFactory.
If you really want to do that, just implement IControllerFactory interface (or try to derive from DefaultControllerFactory).
Then your Application_Start register your controller factory using ControllerBuilder.Current.SetControllerFactory method.
Look at the ControllerFactory documentation and to the MVC source code for details.

What you're asking and what your example shows are two different things; depending on which one you want to achieve, you may or may not need to do any work.
There are two requirements for a class to be a controller in the MVC Framework:
It has to have a class name of Name + "Controller"
It has to have a parameterless public constructor.
Your sample "normal" MVC layout is actually not valid:
MyMvcProject\Controllers\
MyController1.cs
MyController2.cs
MyController3.cs
Those classes wouldn't be found by MVC because they don't have the correct name, regardless of which folder they are in.
If all you want to do is change the namespace/folder names, that "just works", assuming you name them the same as the appropriate route segment(s):
MyMvcProject\MyGroup1\
Page1Controller.cs
Page2Controller.cs
MyMvcProject\MyGroup2\
Page3Controller.cs
MyMvcProject\Areas\Area1\
Area1Page1Controller.cs
This walkthrough (written for MVC 2 but works just as well in MVC3) shows you how to support Areas with the default controller behavior.
If you actually want to name them SomethingController1 or SomethingElseController5, or otherwise change the route -> classname mappings, then you do need to implement a custom ControllerFactory, and inject it into the MVC pipeline.
There are plenty of examples on the web on how to do this, including the one posted earlier.

Can I add an ASPX page to an MVC project WITHOUT involving any Controllers?

I have an interesting situation where I need to quickly provide a feature to a customer prior to our normal build schedule and outside of our normal build repository. I need it to go live tonight, without a recompile.
Our site is deployed with everything compiled into a DLL, besides the Views. This means that at anytime I can edit the Views on the fly in the middle of the day. Is there a way I can add a new page that can be invoked via HTTP GET or POST so that I can do some things I would normally do in a Controller without actually making a new Action, etc? I know this is not a good methodology and it won't be the long term solution, I just need a plan... business is business after all.
Edit: I also cannot edit the Global.asax routing table, it is also compiled.

The first thing you'd have to do is pull out your Routes into XML files so you could add routes on the fly (all it'd do is recycle the App-Pool). I also recommend pulling the Routes out of the web.config into their own .config file, that's referenced in the web.config.
The second thing is you would have to mix Webforms with ASP.NET MVC if you wanted to do this.
It's important to note that using UrlParameter.Optional is problematic with XML based routing, at least I never got it to work.

I believe because of the way routing works in MVC it will try to find a valid path using the Routing system first. Failing that it should look for the aspx page using the normal method of just looking for the file. Keep in mind that aspx files (or razor files) that are just asp.net pages should not be in the Views folder, as MVC apps are configured to refuse serving up files in that directory. I'm assuming your're just talking about a single page or two? Anything more complex than that and I would look at trying to separate them more strongly as in the article mentioned above.

You could mix classic webforms with MVC.

I'm almost positive you could add a new Controller class to the App_Code folder and it would get picked up without a compile needed.
I guess it all depends if you have a convention based route that will hit it or not.