Сборка Workflow Foundation 4 по другому пути с использованием кодовой базы / пути зондирования
У нас есть длительный рабочий процесс, реализованный с использованием сервисов WF4. В настоящее время у нас есть проблема, заключающаяся в том, что при развертывании новой версии рабочего процесса существующие постоянные экземпляры не загружаются. Я видел на Как вы управляете версиями в Workflow Foundation? (что затем привело к http://msmvps.com/blogs/theproblemsolver/archive/2008/09/10/versioning-long-running-workfows.aspx?ocid=aff-n-we-loc--DEV40909&WT.mc_id=aff-n-we-loc--DEV40909) по управлению различными версиями с помощью href-подсказки кодовой базы в app.config.
Это работает для простого рабочего процесса, который не имеет каких-либо пользовательских операций с кодом - я развернул XAMLX в приложении IIS 7, создал подкаталог (bin/v1) и поместил туда библиотеки DLL, а также указал путь зонда, как показано ниже:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="v1" />
<probing privatePath="bin/v1" /> <!-- one of these is probably redundant... -->
</assemblyBinding>
</runtime>
Однако, когда я добавляю пользовательский код действия, XAMLX, кажется, имеет ссылку на сборку, как показано ниже (я исключил стандартные сборки из этого):
<WorkflowService mc:Ignorable="sap sads" ConfigurationName="Service1"
sap:VirtualizedContainerService.HintSize="307,436" Name="Service1"
mva:VisualBasic.Settings="Assembly references and imported namespaces serialized as XML namespaces"
xmlns="http://schemas.microsoft.com/netfx/2009/xaml/servicemodel"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
...
xmlns:p1="http://schemas.microsoft.com/netfx/2009/xaml/activities"
**xmlns:p2="clr-namespace:PromotionWorkflowV1;assembly=PromotionWorkflowV1"**
xmlns:s="clr-namespace:System;assembly=mscorlib"
...
>
Когда я пытаюсь перейти к службе WF в браузере, я получаю сообщение об ошибке парсера, например:
Cannot create unknown type '{clr-namespace:PromotionWorkflowV1;assembly=PromotionWorkflowV1}SubmitActivity'.' Line number '42' and line position '6'.
Я предполагаю, что это потому, что WF не смотрит на путь исследования, пока он анализирует XAMLX? Есть ли что-то еще, что можно сделать, чтобы я мог добиться контроля версий в этом сценарии?
Спасибо, -Сринивас
1 ответ
@ Уилл, я сделал iisreset и смог также зафиксировать эту привязку. Спасибо!
Я просмотрел логи fuslogvw, и оказалось, что проблема заключалась в том, как я указывал пути исследования. Следующие:
<probing privatePath="v2" />
<probing privatePath="bin/v2" />
только чтит первый путь, а не второй. Первое не удалось, так как считалось, что это из корня веб-приложения, а второе не было рассмотрено.
Когда я удалил первый путь, привязка прошла успешно. Другой вариант указания нескольких путей в документации MSDN:
<probing privatePath="v2;bin/v2" />
Я также обнаружил, что пробел после ";" также не работает, поскольку в пути также используется пробел, поэтому он стал "D:/myDir/ bin/v2").
Одним из наблюдений было то, что файл XAMLX имеет только имя сборки, а не версию. Я вручную отредактировал его, чтобы указать номер версии, и теперь он также подбирает правильную версию DLL.
Спасибо за вашу помощь! (Плюс напоминание не предполагать, а читать документацию чуть внимательнее.:-))