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

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

2 голосов
/ 16 марта 2010

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

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

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

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

[Update]

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

Ответы [ 4 ]

6 голосов
/ 18 сентября 2012

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

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

3 голосов
/ 16 марта 2010

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

0 голосов
/ 19 апреля 2012

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

0 голосов
/ 24 марта 2010

Кажется маловероятным, что я могу ссылаться на код в сборке моего веб-приложения 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 так плохо, и он вернется, чтобы укусить меня? ...

...