Сбой компиляции страницы ASPX

Question

Мы разрабатываем веб-приложение, которое позволяет администраторам загружать подключаемые модули. Все плагины хранятся в специальной папке вне корня приложения (скажем, C: \ Plugins) и динамически загружаются через Assembly.LoadFrom (). По большей части это работает просто отлично: экземпляры WebControls в плагинах создаются и загружаются, пользовательские классы работают как положено и т. Д.

Мы используем пользовательский 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 ()%>», компиляция завершается неудачно.

Как мы можем заставить это работать?

UPDATE:

Мы попытались использовать полные имена. Нет разницы. Невозможно пройти - это ошибка компиляции при переходе на страницу aspx. Пространства имен не будут проблемой в этом случае (так как это было от внешнего плагина dll)

UPDATE2:

Джоэл, я думаю, что вы на что-то. К сожалению, редактирование web.config для включения этих сборок не является частью дизайна. По сути, мы хотим, чтобы плагины были полностью динамическими - поместите их в папку, перезапустите приложение и будьте готовы к работе.

Answer 1

Assembly.LoadFrom является динамическим (с поздним ограничением), что означает, что тип не включен во время компиляции, поэтому ссылки на содержащиеся в нем классы недопустимы. Вам необходимо указать ссылку на сборку, чтобы она была включена в состав класса * .aspx.

Вы можете найти некоторые исходные коды здесь полезными, и я рекомендую попробовать Managed Extensibility Framework , потому что он, возможно, уже решил эту проблему.

Обновление: я нашел ответ на вашу проблему. Хотя это не будет работать в проекте ASP.NET 1.1, оно будет работать для 2.0+. Они реструктурировали конвейер здания для использования BuildProvider, который можно указать в файле конфигурации (web.config). Хотя вам нужно написать свой собственный поставщик сборки, вы можете сделать так, чтобы он автоматически ссылался на все сборки в папке плагинов перед компиляцией. Вот информация о конфигурации и , вот что вам нужно для создания подкласса .

Вот устаревшая копия исходного кода для PageBuildProvider * Mono , вам нужно будет проверить последнюю версию ASP.NET из общего источника MS, скопировать ее и расширить с помощью пользовательских ссылка на сборку, потому что класс, к сожалению, запечатан (но выглядит не очень сложно).

Answer 2

Я никогда не пытался сделать это, но я подозреваю, что ваша страница ASPX, хотя она загружена из сборки вашего плагина, компилируется в среде ASP.NET, которая не имеет ссылки на вашу сборку плагина - что объясняет почему полное имя не работает.

Вы пытались добавить ссылку на MyPlugin.dll в тег compilation / сборки в файле web.config?

Answer 3

Вы пытались полностью определить пространство имен для вспомогательного класса? Это публично? Это в той же сборке? Возможно, он также находится в другой сборке.

Попробуйте войти в код и проверить тип InternalHelperClass. Более новые методы компиляции «на сайте» часто добавляют пространства имен, которые вы не ожидали. НАПРИМЕР. класс для веб-страницы имеет пространство имен ASP.MyWebPage. Иногда пространства имен добавляются в зависимости от того, в какой папке они находятся.