Почему EasyNetQ терпит неудачу, когда он прошел ILMerged?

Question

Я создаю компонент плагина для Dynamics CRM 2015. Поскольку мы развертываем в CRM Online, плагин должен быть единой подписной DLL - мы не можем развернуть дополнительные DLL вместе с ним, и мы не можем ничего помещать в GAC, поэтому я использую ilmerge.exe, чтобы объединить и подписать мои сборки в одну DLL.

Проблема заключается в том, что, насколько я вижу, EasyNetQ/RabbitMQ не отправляет никаких сообщений, когда они перемещаются. Я могу воспроизвести это локально, поэтому это не проблема среды CRM.

У меня есть три библиотеки DLL

• MyPlugin.dll
• EasyNetQ.dll
• RabbitMQ.Client.dll

Если я ссылаться на эти библиотеки DLL отдельно в моем тестовом коде и invoke .Execute() в моем коде плагина, все работает красиво

У меня есть шаг после сборки:

$(SolutionDir)packages\ilmerge.2.14.1208\tools\ilmerge.exe /out:$(TargetDir)MyPlugin.Ilmerged.dll /keyfile:$(TargetDir)plugin_key.snk $(TargetDir)EasyNetQ.dll $(TargetDir)RabbitMQ.Client.dll $(TargetDir)MyPlugin.dll

Это выплевывает один подписанный DLL, MyPlug.Ilmerged.dll, что (теоретически!) Содержит EasyNetQ, RabbitMQ и мой плагин код. Все прекрасно компилируется. Если я удалю отдельные ссылки DLL из своего тестового кода и добавлю одну ссылку на эту сборку с ILMerged, она компилируется отлично, а код не генерирует никаких исключений - я просто не получаю сообщений, появляющихся в очереди.

Возможно, это связано с перенаправлением связывания сборки, которое EasyNetQ использует для разрешения RabbitMQ? Или что-то? Я полностью зациклен на том, как ILMerge может заставить его терпеть неудачу без каких-либо ошибок или чего-то еще.

Answer 1

ОК, я включил ConsoleLogger и выдает сообщения ARE, которые публикуются, но они публикуются на другой обмен, потому что квалифицированное имя типа моих сообщений изменяется с помощью этапа ILMerge

ILMerged:

DEBUG: Заявленный Обмен: MyPlugin.CrmEntityChange: MyPlugin.Ilmerged тип: тема, долговечный: Правда, Автоудаление: Ложь, задержка: Ложные DEBUG: Опубликовано обмена: «MyPlugin.CrmEntityChange: MyPlugin .Ilmerged ', ключ маршрутизации:' person.crm2015.changed ', correId:' 094fbde9-f7a3-4884-82d7-8a1792e38d6e '

исключен из группы:

DEBUG: Заявленный Обмен: MyPluginCrmEntityChange Типа MyPlugin: тема, долговечны: Правда, Автоудаление: Ложь, задержка: Ложные DEBUG: Опубликован обмен: «MyPlugin.CrmEntityChange: MyPlugin », маршрутизация ключ: 'person.crm2015.changed', CorrelationId: 'e41b4360-04c8-4210-917a-17540d41f3ce'

Так что же происходит, что мой издатель посылает сообщения типа MyPlugin.Ilmerged.CrmEntityChange b ut мой абонент прослушает MyPlugin.CrmEntityChange - и поскольку ничто никогда не подписывается на MyPlugin.Ilmerged.CrmEntityChange сообщений, на хосте не создается очередь, и сообщения просто отбрасываются.

Решение - ну, my решение - это изменить шаг после сборки, чтобы ILMerged DLL имела то же имя, что и сборка, содержащая мои типы сообщений. Это означает, что вы получаете две разные библиотеки DLL, которые называются MyPlug.dll, - это сборка ILMerged, которая развертывается в CRM, а другая - эталонная сборка, используемая подписчиком, - но поскольку эти сборки никогда не должны развертываться на одном и том же системы, я готов рискнуть.