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

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

DotNetNuke.Services.Exceptions.ModuleLoadException: тип «XXX.ParametersControl.ParameterTabControl» неоднозначен: он мог происходить из сборки «C: \ Clients \ XXX \ Code \ Reporting \ DotNetNuke_BaseInstall \ bin \ XXX.KPI_Configurable_Chart». 'C: \ Clients \ XXX \ Code \ Reporting \ DotNetNuke_BaseInstall \ bin \ XXX.Survey_Grid.DLL'. Пожалуйста, укажите сборку явно в имени типа.

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

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

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

‹% @ Register src =" ParameterControl / ParameterTabControl.ascx "tagname =" 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 и не быть привязанным к элементу управления основного модуля, при этом позволяя мне запрашивать свойства и объекты в элементе управления, чтобы установить и получить его свойства?


dotnetnuke ascx web-user-controls dotnetnuke-module dotnetnuke-5
person Chris Chubb    schedule 18.02.2010    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

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

Дополнительную информацию см. В документации @ Register.

person Lance McNearney    schedule 18.02.2010
comment
+1 - это должно настроить ОП в правильном направлении. Каждый раз, когда вы видите неоднозначное сообщение об ошибке, вам нужно добавить к нему дополнительный контекст. - person Ian Robinson; 20.02.2010
comment
Но это предполагает, что у меня должен быть подписанный, строго именованный элемент управления, верно? Я не подписывал создаваемую DLL. У меня уже есть часть сборки, и единственным определяющим отличием будет PublicKeyToken. - person Chris Chubb; 20.02.2010
comment
Сборка и пространство имен вашего компонента не имеют ничего общего с подписью. Сборка - это просто имя файла .dll, который ASP.Net должен искать для вашего класса. Пространство имен - это полный путь к пространству имен компонента внутри этой сборки. - person Lance McNearney; 20.02.2010

arrow_upward
0
arrow_downward

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

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

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

Спасибо, Лэнс и Ян.

person Chris Chubb    schedule 20.02.2010