views:

429

answers:

2

I've added an App_Code directory to my ASP.NET MVC project so that I get dynamic compilation for plugins.

Only slight annoyance is that when developing new plugins, I don't get intellisense on classes inside the App_Code directory.

Currently I am creating them in another directory inside my project and then copying them into App_Code.

is there any way around this?

[Update]

I've posted an "answer" below. Technically this answers the question as based on my own specification, the use of tools (i.e. intellisense) should not be required to create plugins. However, this did prompt a question of how I may achieve a dynamically compiled plugin framework without using App_Code. Since this question is so different from the original, I will raise it separately.

+1  A: 

ASP.NET MVC uses a web application project in contrast to a web site. A web application project needs to be compiled. The App_Code directory makes no sense in such application type.

Darin Dimitrov
@Darin, I understand the difference between the project types, this is however, a VS thing, not a runtime thing. The reason for using the App_Code directory is that I want people to be able to add plugins easily, without having to open the application in VS/VWDE, add the plugin and recompile. It also offers the benefit that people can write plugins in their preferred language, whether it be c#, vb.net or ruby. Is using App_Code such a bad thing? This is how apps like BlogEngine work and it's great from an extensibility perspective.
Ben
A: 

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

Ben