Компиляция / встраивание пользовательских элементов управления ASCX для повторного использования в нескольких веб-приложениях - PullRequest
Новая
       10

Компиляция / встраивание пользовательских элементов управления ASCX для повторного использования в нескольких веб-приложениях

4 голосов
/ 17 июня 2009

Здесь я натолкнулся на настоящую голову ... и это, кажется, одна из самых разочаровывающих тем ASP.NET.

У меня есть сборка, которая реализует множество пользовательских вещей Linq, которые по своей сути не имеют веб-функциональности. У меня есть дополнительная сборка, которая расширяет эту сборку специфическим веб-поведением.

Поведение, характерное для Интернета, сопровождается парой пользовательских элементов управления, размеченных внутри шаблонных пользовательских элементов управления ASCX.

У меня проблемы с наложением хорошей сборки на эту сборку, чтобы ее было легко развернуть для использования в других приложениях. Позвольте мне пробежаться через то, что я пробовал до сих пор:

  1. Копирование файлов ASCX в веб-приложение-потребитель с использованием событий сборки; далеко от идеала и настоящий кошмар развертывания .
    • Реализовал пользовательский VirtualPathProvider и внедрил шаблоны ASCX в сборку как встроенные ресурсы. К сожалению, при использовании директивы Register в приложении-потребителе он создает объявление конструктора как UserControl, где мне потребуется объявление фактического типа элемента управления; непредвиденный (обычно) и нежелательный .
    • Создан проект веб-развертывания для компиляции UserControls, но скомпилированные пользовательские элементы управления затем становятся частью другой сборки и больше не выходят из определений классов в моей веб-сборке - сборка должна создавать их экземпляры в зависимости от контекст запроса .

Таким образом, номер 1 - просто дерьмо, номер 2 не дает мне поддержку типов, которую я желаю, и номер 3, я думаю, я собираюсь найти разумное решение с помощью:

  • Поместите все неконтрольные классы в папку App_Code, подготовьте фабричный класс, который с помощью отражения создаст объект нужного типа элемента управления, и ожидайте, что отражаемый тип будет присутствовать в выходных данных развертывания (надеюсь, гарантировано наличием атрибута ClassName в директиве Control).

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

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

1 Ответ

2 голосов
/ 18 июня 2009

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

  1. Старайтесь не помещать классы в App_Code, если они не являются автономными или вспомогательными классами, ASP.NET рассматривает это как папку speshul , значение которой потеряно для меня, хаос, замешательство и хаос , Однако код в этой папке действительно выводится в проекте веб-развертывания.
    • Обратите особое внимание на имена ваших сборок, их корневые пространства имен и имя выходной сборки развертывания - вы получите access is denied ошибок, если у вас возникнут конфликты имен во время процесса aspnet_merge.
    • В конечном итоге вы, скорее всего, в конечном итоге развернете 2 сборки, я попытался создать только одну, но выходные данные развертывания все еще указывали на определения типов в исходной сборке. Это не проблема, если у вас нет других типов в вашем проекте веб-приложения - у меня так, это было проблемой для меня. В моем случае мой окончательный результат был:
    • <Organisation>.<TechnologyName>.Web.DLL - Сборка скомпилированного веб-приложения (содержащая шаблоны ASCX)
    • <Organisation>.<TechnologyName>.Web.UI.DLL - Сборка ASP.NET скомпилированного UserControl, созданная в рамках проекта веб-развертывания
    • Часто выполняйте очистку и проверяйте, что пути bin и obj проекта веб-приложения очищаются от любого предыдущего мусора, созданного, если вы, возможно, еще не завершили схему именования пространства имен или сборки - проект веб-развертывания будет весьма стремится включить их, вызывая мелкий беспорядок.
    • Проверьте импортированные пространства имен, компилятору ASP.NET нравится ссылаться на директиву Import в шаблоне ASCX, и он также учитывает импортированные пространства имен, присутствующие в элементе web.config * <configuration><system.web><pages><namespaces>, подстройте, если вы неизвестны определения, появляющиеся в процессе развертывания.

Имейте немного терпения, это довольно сложно! Но в конце вы получите несколько хороших распространяемых UserControls!

Уф!

...