It seems unlikely that I can reference code in my MVC web app assembly from App_Code at design time. I believe this is just the nature of Web Application projects in Visual Studio and the fact that code in the App_Code directory is being compiled into a different assembly.
In my original question I explained that I was wanted to use App_Code because of it's dynamic compilation capabilities. Thinking about my extensibility requirements, the fact that intellisense doesn't work property should not be a concern as the whole point is that an IDE is not required to develop plugins - if I was going to open up Visual Studio to develop them I may as well just use class libraries.
So thinking about my plugin architecture, I am fine with the notion of defining my plugins (http://weblogs.asp.net/justin_rogers/articles/61042.aspx) and I can do automatic loading of plugins in a specific directory like so:
var assemblies = new List<Assembly>();
var di = new System.IO.DirectoryInfo(Server.MapPath("~/Plugins"));
di.GetFiles("*.dll").ToList().ForEach(x => {
assemblies.Add(Assembly.LoadFrom(x.FullName));
});
List<Plugin> ExternalPlugins =
Plugin.InitializePlugins(assemblies).ToList();
The only reason for not using /bin was performance. However, since the plugin project referenced the main web project I ended up having to use post build events to keep everything in check - which I didn't like.
So a better solution (as suggested by a number of people) is to use a configuration file to define plugins and drop the dlls into bin as normal.
But with all these different approaches I am skirting round the initial requirement - to be able to tweak plugins on the fly using no IDE and without a need to manually compile the application.
So in this case, is using App_Code really so bad and will it come back to bite me?...