Как я могу использовать один и тот же веб-контроль пользователя в двух разных модулях DotNetNuke (DNN)?

Question

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

DotNetNuke.Services.Exceptions.ModuleLoadException: Тип 'XXX.ParametersControl.ParameterTabControl' неоднозначно: это может прийти из сборка 'C: \ Clients \ XXX \ Code \ Отчеты \ DotNetNuke_BaseInstall \ Bin \ XXX.KPI_Configurable_Chart.DLL' или из сборки 'C: \ Clients \ XXX \ Code \ Отчеты \ DotNetNuke_BaseInstall \ Bin \ XXX.Survey_Grid.DLL. Пожалуйста, укажите сборку явно в имени типа.

Оба модуля устанавливаются и работают без дополнительной настройки пользовательского интерфейса.

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

Включение в основной модуль ASCX осуществляется следующим образом:

<% @ Регистрация SRC = "ParameterControl / ParameterTabControl.ascx" Тэг = "ParameterTabControl" tagprefix = "uc1"%>

Как видите, я включаю управление интерфейсом, получая его из подкаталога, который я реализую как внешний Subversion.

Я ссылаюсь на объекты и свойства элемента управления в коде .vb основного модуля следующим образом:

ParameterTabControl1.DateRangeTabVisible = True
If (ParameterTabControl1.StartDate Is Nothing) Then
     ParameterTabControl1.StartDate = DateAdd(DateInterval.Day, -90, Now)
End If

Какие-нибудь советы о том, как спроектировать это, чтобы этого не произошло? Какой-нибудь способ заставить субконтроль ASCX подключаться только к своей собственной DLL и не быть привязанным к основному элементу управления модуля, в то же время позволяя мне запрашивать свойства и объекты в элементе управления для установки и получения его свойств?

Answer 1

Вы пытались указать общую сборку и / или пространство имен в своем теге @ Register? Я не знаю точных значений для вашего общего компонента, но вы можете указать, какое именно пространство имен и сборку использовать:

<%@ Register src="ParameterControl/ParameterTabControl.ascx"
tagname="ParameterTabControl" tagprefix="uc1" assembly="XXX.SharedControls"
namespace="My.Shared.Control" %>  

Ознакомьтесь с документацией @ Register для получения дополнительной информации.

Answer 2

Я думаю, что я решил это навсегда, используя обходной путь, чтобы разорвать связь между проектами. Казалось, проблема в том, чтобы они оба были в одном и том же решении в качестве основного элемента управления. Я вытащил ParameterTabControl из решений для модулей DNN и просто открыл его во второй копии VS. Без «ссылки на проект» в VS он просто связывает код с DLL напрямую и не импортирует пространство имен DLL.

Мне пришлось добавить некоторые события после сборки в ParameterTabControl, чтобы автоматически выдвинуть новую DLL на платформу тестирования, чтобы предотвратить проблемы контроля версий между двумя решениями модуля DNN, но это было не слишком много работы. Тогда последняя общая DLL всегда доступна обеим, и они обе видят одну и ту же версию при компиляции. Это взлом, но это работает.

На этот раз я был приятно удивлен как полнотой, так и правильностью выдаваемой и отображаемой ошибки.

Спасибо Лэнсу и Йену.