Ошибка компиляции страницы ASPX
Мы разрабатываем веб-приложение, которое позволяет администраторам загружать плагины. Все плагины хранятся в специальной папке вне корня приложения (скажем, C: \ Plugins) и динамически загружаются через Assembly.LoadFrom (). По большей части это работает отлично: элементы управления WebControl в подключаемых модулях создаются и загружаются, настраиваемые классы работают должным образом и т. д.
Мы используем настраиваемый VirtualPathProvider для извлечения ресурсов из этих подключаемых модулей. Итак, чтобы получить встроенный файл ASPX, вам нужно просто ввести «/MySite/embeddedResource/?Assembly=MyPlugin&Resource=MyPage.aspx». И это тоже отлично работает: встроенный файл ASPX компилируется и обслуживается как обычная страница.
Однако проблема возникает, когда встроенный файл .aspx (внутри динамически загружаемого подключаемого модуля) ссылается на класс внутри той же сборки подключаемого модуля. Мы получаем такие ошибки компиляции, как «не удается найти тип или сборку MyPlugin». Это странно, потому что очевидно, что он извлекает файл .aspx из MyPlugin; так как он может не найти?
Итак, я надеюсь, что вы можете мне с этим помочь. Плагин будет выглядеть так:
MyPlugin.dll:
- InternalHelperClass.cs
- MyPage.aspx (ресурс без файла .cs)
Когда MyPage.aspx содержит что-то вроде «<% = InternalHelperClass.WriteHelloWorld ()%>», компиляция не выполняется.
Как мы можем заставить это работать?
Обновлено:
Мы пробовали использовать полностью определенные имена. Нет разницы. Пошагово невозможно - это ошибка компиляции при переходе на страницу aspx. Пространства имен в этом случае не будут проблемой (так как это было из внешней библиотеки подключаемого модуля).
ОБНОВЛЕНИЕ2:
Джоэл, я думаю, ты что-то понял. К сожалению, редактирование web.config для включения этих сборок не является частью дизайна. По сути, мы хотим, чтобы плагины были полностью динамическими - поместите их в папку, перезапустите приложение и будьте готовы к работе.
Ответы 3
Вы пробовали полностью определить пространство имен для вспомогательного класса? Это публично? Он в той же сборке? Возможно, это в другой сборке, которую тоже нужно загрузить.
Попробуйте войти в код и проверить тип InternalHelperClass. Новые методы компиляции "веб-сайтов" часто добавляют пространства имен, которых вы не ожидали. НАПРИМЕР. класс для веб-страницы имеет пространство имен ASP.MyWebPage. Иногда пространства имен добавляются в зависимости от того, в какой папке они находятся.
Я никогда не пытался это сделать, но подозреваю, что ваша страница ASPX, хотя она загружена из сборки вашего плагина, компилируется в среде ASP.NET, которая не имеет ссылки на вашу сборку плагина, что объясняет, почему полностью квалифицированное имя не работает.
Вы пробовали добавить ссылку на MyPlugin.dll в тег compilation / assemblies в вашем файле web.config?
Assembly.LoadFrom является динамическим (поздняя привязка), что означает, что тип не включается во время компиляции, поэтому ссылки на содержащиеся в нем классы недействительны. Вам необходимо указать конкретную ссылку на сборку, чтобы она была включена как часть компиляции класса * .aspx.
Вы можете найти часть исходного кода здесь полезной, и я рекомендую попробовать Фреймворк управляемой расширяемости, потому что он, возможно, уже решил эту проблему.
Обновление: я нашел то, что, по моему мнению, является ответом на вашу проблему. Хотя это не будет работать в проекте ASP.NET 1.1, это будет для 2.0+. Они реструктурировали конвейер сборки, чтобы использовать BuildProvider, который можно указать в файле конфигурации (web.config). Хотя вам нужно написать свой собственный поставщик сборки, вы можете создать тот, который автоматически ссылается на все сборки в папке Plugins перед компиляцией. Вот информация о конфигурации и вот что вам нужно для подкласса, чтобы сделать это.
Вот устаревшая копия исходного кода для PageBuildProvider Mono, вам нужно будет проверить последнюю реализацию ASP.NET из общего источника MS, скопировать ее и расширить с помощью вашей пользовательской ссылки на сборку, потому что класс, к сожалению, запечатан (но это не выглядит ужасно сложным).