Управление слабосвязанными ссылками на сборки, возникающими в результате использования атрибута Designer.

Мы создаем множество компонентов, WinForms, действий рабочего процесса и т. Д., И кое-что, что мы часто используем, - это атрибут «Дизайнер». Обычно во время начальной разработки атрибут Designer используется со стилем [Designer(typeof(DesignerType))], чтобы все работало, а затем он преобразуется в [Designer("AssemblyQualifiedTypeName")], что позволяет удалить библиотеку конструктора из справочного списка компонента - это устраняет необходимость в потребителю компонента необходимо развернуть конструкторскую DLL вместе со своим продуктом. Эта практика разделения кода времени разработки и времени выполнения на две отдельные библиотеки DLL является обычной практикой, и я ее сторонник.

Отрицательный побочный эффект заключается в том, что «имя типа с указанием сборки» будет включать версию сборки дизайнерской dll, поэтому при увеличении версии необходимо выполнить «поиск и замену» по всему продукту, чтобы убедиться, что они обновили все ' свободные ссылки »на этого дизайнера.

Наконец, мой вопрос: может ли кто-нибудь порекомендовать лучший метод, который не полагается на «поиск и замену», который может управлять всеми этими ссылками, чтобы гарантировать, что они всегда актуальны? Мы часто получаем, что ленивый разработчик забывает обновить ссылочную строку, в результате чего новая версия компонента связывается с предыдущей версией дизайнерской DLL, которая, конечно же, не развертывается, поэтому поддержка во время разработки теряется. Возможно, какая-то форма прагм, макросов, сценария сборки, магических атрибутов, я не знаю, но должен быть лучший способ сделать это.

Кто угодно? (Благодарность)


person Adam    schedule 01.02.2011    source источник
comment
Почему вы увеличиваете [AssemblyVersion] дизайнера? В этом нет никакого смысла, вы их не развертываете.   -  person Hans Passant    schedule 02.02.2011
comment
Привет, Ганс, мы создаем компоненты для разработчиков и продаем их как SDK, поэтому мы даем компонентную DLL и дизайнерскую DLL нашим клиентам, и они используют компоненты для создания продуктов, они (в свою очередь) развертывают только компонент со своими продукт. Поскольку у них могут быть установлены две или более версий SDK, компоненту необходимо загрузить правильную версию конструктора, как таковую, что необходимо для версии DLL конструктора.   -  person Adam    schedule 02.02.2011


Ответы (2)


Почему бы не создать единого дизайнера, который использует что-то вроде Managed Addin Framework или Activator.CreateInstance внутри, чтобы выбрать и показать дизайнера? С этой техникой атрибут Designer никогда бы не изменился ...

person Alex Dresko    schedule 01.02.2011
comment
Привет, Алекс - как мы относимся к этому? Атрибут DesignerAttribute считывается корневым дизайнером Visual Studio (то есть дизайнером форм или конструктором действий WF). Таким образом, атрибут DesignerAttribute является неизбежным злом, и нет никакого способа (насколько я понимаю) встать между Visual Studio и компонентом. - person Adam; 02.02.2011
comment
Когда VS или конструктор WF видит, что вы применили атрибут к классу, он фактически создает экземпляр этого класса и использует его. Вы знаете это, потому что заказные дизайнеры, которых вы написали, работают так, как ожидалось. Но вместо отображения пользовательского интерфейса вы можете написать код, который динамически создает экземпляр класса, возможно, на основе некоторого параметра конфигурации. Вместо MAF или Activator.CreateInstance вы также можете использовать что-то вроде Spring.NET или Unity. - person Alex Dresko; 02.02.2011
comment
Мне очень жаль, Алекс, я понимаю, что вы описываете, но не вижу, как этого добиться. Visual Studio создает экземпляр конструктора (и это должен быть дизайнер), на который «ссылается» атрибут DesignerAttribute, и я не могу контролировать, что он с ним делает ... обычно для его отображения в окне дизайна. Вы можете объяснить с помощью псевдокода, что вы имеете в виду? - person Adam; 02.02.2011

Делайте это так, как это делает Microsoft. Взгляните на класс AssemblyRef (System.Windows.Forms.dll) в Reflector.

person user2104272    schedule 24.02.2013