Здесь я хочу разделить опасения. Создайте и вставьте всю логику пользовательского интерфейса для пользовательского XML-дизайнера, объектной модели, проверок и т. д. В отдельную сборку. Затем структура пакета должна только зарегистрировать информацию о дизайнере и запросить службу пользовательского интерфейса, и все работает волшебным образом.
Таким образом, мне не нужно играть со сборкой Package framework (Visual Studio Package), когда мне нужно изменить конструктор пользовательского интерфейса.
Этот вопрос также относится ко всему, где вам нужно отделить логику пользовательского интерфейса от фреймворка Skeleton, который его загружает, например плагина.
У меня есть несколько вариантов: модель ServiceProvider, модель плагина или что-то еще.
Приветствуются любые образцы, предложения по выкройкам, ссылки.
Обновление 1: то, что я ищу, - это такая мысль: «Соответствует ли Prism (Composite WPF) всем требованиям? Кто-нибудь работал над проектом / приложением, которое выполняет разделение проблем, как я упоминал выше? И т. Д.» (Я все еще ищу ответы)





То, что вы спрашиваете о швах, очень похоже на разделение проблем, которое пытается обеспечить шаблон MVC.
ASP.NET MVC уже существует с превью 5.
В основном это для Интернета, но я думаю, что они планируют использовать его также для WinForms, но я не уверен.
Я создал VSPackage, который загружает редактор. Редактор находится в отдельной сборке и реализует определенный мной интерфейс. VSPackage работает с интерфейсом, поэтому любые изменения, которые я вношу в редактор (и его сборку), не влияют на VSPackage, пока я не меняю интерфейс.
Да, я этим и закончил. Мы также создали проект PackageSupport, который имеет эти интерфейсы и общую логику, связанную с VS, и это удобно.
Я предпочитаю шаблон Презентатор представления модели
Спасибо за указание, но я искал более точные предложения / образцы того, как это сделать в отношении пакета VSX.