You can add the controllers namespace to the MVC controller builder.

I usually add it an initialisation class of the project where I have my controllers.

[InitializableModule]
public class InitializeDependencies : IConfigurableModule
{


public void Initialize(InitializationEngine context)
{
ControllerBuilder.Current.DefaultNamespaces.Add("My.Class.Library.Namespace.Controllers");

}

public void Uninitialize(InitializationEngine context)
{
}

public void Preload(string[] parameters)
{
}

}

Just curious what is reason for splitting it into separate assembly?

I like to develop features that are "large enough" in separate modules, independent from the website. These features, more often than not, will have code that spreads accross all tiers of the implementation. 

An approach similar to add-ons development in EPiServer or modules in Orchard CMS.

This helps me re-use code between projects, helps in keeping the modules independent from each other, helps in testing single bits of functionality. 

Ok clear. I would on the another hand prefer dumb controllers but clever services or other components that are located outside of web app. That makes possible to reuse the same business logic across multiple "endpoints" - mvc controller, webapi controller, wfc endpoint etc.

Btw, is "controller namespace" supported by "Goto Controller" from View markup in VS? Haven't tried.

Same here, I prefer thin controllers that call rich services. By putting the full vertical slice in separate projects, I can ship them in independent modules.

You make a good point about the consumers but that can also be achieved using this development model.

I just tried the "Goto Controller" and it doesn't work. Tbh, I never use this function in VS. R# shortcuts all the way :)