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

Question

Здесь я нахожусь в настоящей головной царапине ... и, похоже, это одна из наиболее неприятных тем ASP.NET.

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

Веб-специфическое поведение имеет пару пользовательских элементов управления, помеченных внутри ASCX-шаблонов UserControls.

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

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

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

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

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

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

Answer 1

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

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

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

Фу!