ASP.NET MVC使用APP_ code目录 [英] ASP.NET MVC using App_Code directory

问题描述

让我得到的插件动态编译我已经添加了APP_ code目录我的ASP.NET MVC项目。

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

只有轻微的烦恼是，开发新的插件的时候，我没有得到智能感知上APP_ code目录中的类。

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

目前，我在我的项目在另一个目录中创建它们，然后将它们复制到APP_ code。

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

有没有解决这个办法吗？

is there any way around this?

[更新]

我已经张贴了下面的答案。从技术上讲这回答是根据我自己的规范的问题，工具的使用（即智能感知）不应该被要求创建插件。然而，这并提示我怎么可能实现，而无需使用APP_ code动态编译的插件框架的问题。由于这个问题是从原来如此不同，我会另行提出。

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.

推荐答案

这似乎不大可能，我可以在设计时参考code从APP_ code我的MVC的Web应用程序组件。我相信，这仅仅是在Visual Studio Web应用程序项目的性质和事实，即在APP_ code目录code被编译成不同的组件。

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.

在我原来的问题我解释说，我是想用APP_ code，因为它是动态编译能力。我的可扩展性要求的思考，事实上，智能感知不工作性质不应该是一个问题，因为整个的一点是，一个IDE是的不可以开发插件 - 如果我去开拓视觉Studio开发他们，我可能也只是使用类库。

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.

所以，思考我的插件架构，我很好的定义我的插件的概念（http://weblogs.asp.net/justin_rogers/articles/61042.aspx），我可以做插件的自动加载在一个特定的像这样的目录：

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();

不使用/ bin中的唯一原因是性能。然而，由于该插件项目中引用的主要web项目我最后不得不使用后生成事件，以保持在检查的一切 - 我不喜欢

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.

因此​​，一个较好的解决方案（如由许多人建议的）是使用一个配置文件来定义插件和所述的DLL拖放到仓为正常。

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.

但是与所有这些不同的方法，我踢脚轮的初始需求 - 能够调整使用没有IDE和动态插件而不需要手动编译应用程序

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.

因此​​，在这种情况下，使用APP_ code真的那么糟糕，将它回来咬我？......

So in this case, is using App_Code really so bad and will it come back to bite me?...

这篇关于ASP.NET MVC使用APP_ code目录的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！