Перенаправление конструктора Windows Workflow Foundation 4.0 с настраиваемыми действиями - PullRequest
1 голос
/ 28 декабря 2010

У меня есть несколько рабочих процессов WF 4.0, которые я создал для приложения, которое разрабатывает моя компания.Некоторые из этих рабочих процессов просты, а некоторые очень сложны (например, много шагов, несколько разных типов действий, пользовательских действий).Для многих из этих рабочих процессов я создал несколько пользовательских операций с кодом для поддержки некоторых внутренних типов процессов.

Рабочие процессы работают отлично, и у нас было очень мало проблем с их поддержкой в ​​VS 2010. Теперь мы хотим перенести эту ответственность на наших бизнес-пользователей, поэтому я создал приложение WPF для переоснащенияWF дизайнер (по образцам MS).Моя проблема заключается в том, что когда я открываю один из рабочих процессов, который содержит настраиваемые действия кода, эти действия представляются в виде красных полей с сообщением об ошибке «Не удалось загрузить действие из-за ошибок в XAML».

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

Company.Application.Workflow.Designer

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

Company.Application.Workflow.Data.Activities

Как я уже упоминал, библиотека установлена ​​в качестве ссылки в проекте дизайнера, и я вижу еекопируется в вывод при сборке проекта.Я также включил ссылку в XAML основного разработанного приложения.

Чего мне не хватает?

1 Ответ

0 голосов
/ 29 декабря 2010

Здесь может быть что-то не так. Например, вы установили LocalAssembly при использовании XamlXmlReader? См. здесь для примера. Другая проблема может быть в том, что ваши действия загружаются просто отлично, но связанные с ними дизайнеры не найдены. Вы также можете использовать событие AppDomain.CurrentDomain.AssemblyResolve, чтобы увидеть, какие сборки загружаются и дают сбой. Или даже лучше использовать Fuslogvw.exe для той же цели.

...