Кажется маловероятным, что я могу ссылаться на код в моей сборке веб-приложения 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 в bin как обычно.
Но со всеми этими различными подходами я обхожу исходное требование - иметь возможность настраивать плагины на лету без использования IDE и без необходимости вручную компилировать приложение.
Итак, в этом случае, действительно ли использование App_Code так плохо, и он вернется, чтобы укусить меня? ...
person
Ben Foster
schedule
23.03.2010
