ASP.NET MVC с использованием каталога App_Code

Я добавил каталог App_Code в свой проект ASP.NET MVC, чтобы получить динамическую компиляцию для плагинов.

Лишь небольшое раздражение вызывает то, что при разработке новых плагинов я не получаю intellisense для классов внутри каталога App_Code.

В настоящее время я создаю их в другом каталоге внутри моего проекта, а затем копирую их в App_Code.

есть ли способ обойти это?

[Обновить]

Я разместил "ответ" ниже. Технически это отвечает на вопрос, поскольку основанный на моей собственной спецификации, использование инструментов (т.е. intellisense) не должно требоваться для создания плагинов. Тем не менее, это вызвало вопрос о том, как я могу получить динамически скомпилированную структуру плагинов без использования App_Code. Поскольку этот вопрос так сильно отличается от оригинала, я подниму его отдельно.

4 ответа

Решение

Кажется маловероятным, что я могу ссылаться на код в сборке моего веб-приложения MVC из App_Code во время разработки. Я считаю, что это просто природа проектов веб-приложений в Visual Studio и тот факт, что код в каталоге App_Code компилируется в другую сборку.

В своем первоначальном вопросе я объяснил, что хотел использовать App_Code из-за его возможностей динамической компиляции. Думая о моих требованиях к расширяемости, тот факт, что intellisense не работает со свойством, не должен вызывать беспокойства, поскольку весь смысл в том, что IDE не требуется для разработки плагинов - если я собираюсь открыть Visual Studio для их разработки, я могу, как ну просто используйте библиотеки классов.

Поэтому, думая о моей архитектуре плагинов, я в порядке с понятием определения моих плагинов ( http://weblogs.asp.net/justin_rogers/articles/61042.aspx), и я могу сделать автоматическую загрузку плагинов в определенном каталоге, например, так:

            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 была производительность. Однако, так как проект плагина ссылался на основной веб-проект, мне пришлось использовать события после сборки, чтобы контролировать все - что мне не нравилось.

Таким образом, лучшее решение (как предложено многими людьми) состоит в том, чтобы использовать файл конфигурации для определения плагинов и помещать dll в корзину как обычно.

Но со всеми этими различными подходами я обходил первоначальное требование - иметь возможность настраивать плагины на лету, не используя IDE, и не нужно вручную компилировать приложение.

Так что в этом случае, действительно ли использование App_Code так плохо, и он вернется, чтобы укусить меня?...

Вы можете попробовать изменить файлы "Build Action" в свойствах с "Compile" на "Content". Затем они будут скомпилированы как веб-сайт. Статья ниже объясняет это:

http://vishaljoshi.blogspot.co.uk/2009/07/appcode-folder-doesnt-work-with-web.html

ASP.NET MVC использует проект веб-приложения в отличие от веб-сайта. Проект веб-приложения должен быть скомпилирован. App_Code Каталог не имеет смысла в таком типе приложения.

Есть ответ. Для MVC3 как минимум. Не открывайте раствор как раствор. Откройте его как веб-сайт из локального IIS (при условии, что вы его так запустите). Затем вы увидите ваш динамический код app_code, обнаруженный с intellisense. Но вы не сможете просматривать другие библиотеки кода, находящиеся снаружи. Для этого вам понадобится еще один экземпляр студии и открытия.

Другие вопросы по тегам