To have your api controller in a seperate dll you'll have to trigger the loading of that very early in the sequence, like in application start
GlobalConfiguration.Configuration.Services.Replace(typeof(IAssembliesResolver), new AuxAssemblyResolver());
So essentially you'll derive from a standard IAssembliesResolver and add your stuff to custom load wherever you've placed your definition.
public class AuxAssemblyResolver : IAssembliesResolver
{
public ICollection<Assembly> GetAssemblies()
{
List<Assembly> baseAssemblies = AppDomain.CurrentDomain.GetAssemblies().ToList();
return baseAssemblies;
}
}
I did something like that myself when making a subscription controller that i wanted out of the MVC project recently, the funny bit is that the assembly to load in my case a business assembly handling payments actually get's double loaded if you include the code to actively load it ... go figure, but this way loading whatever domains the the appdomain manages to pick up the externally defined assembly, presumably because the project referenced it.
I'm still a bit puzzled why making an auxilliary assemblies resolve that in effect doesn't do anything you wouldn't presume any assembly resolver would already do, does the trick but at least in my case it did.
In principle of cause actually loading the assembly is what should make the class available for instantiation so i left the do-good code commented in myself, but uncommenting it produces ambiguity and as that bit then worked i eventually decided it was not my windmill to conquer, that why.
Hope this helps