Почему EasyNetQ молча дает сбой, когда он был ILMerge?

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

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

У меня есть три DLL

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

Если я ссылаюсь на эти библиотеки DLL отдельно в своем тестовом коде и вызываю .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 может вызывать сбой без каких-либо ошибок или чего-то еще.


rabbitmq dynamics-crm easynetq ilmerge
person Dylan Beattie    schedule 31.07.2015    source источник

Ответы (1)


arrow_upward
3
arrow_downward

ОК, я включил ConsoleLogger и обнаружил, что сообщения публикуются, но они публикуются на другом обмене, потому что полное имя типа моих сообщений изменяется на шаге ILMerge.

ILОбъединено:

DEBUG: Объявлен Exchange: MyPlugin.CrmEntityChange:MyPlugin.Ilmerged type:topic, durable:True, autoDelete:False, delayed:False DEBUG: Опубликовано для обмена: 'MyPlugin.CrmEntityChange:MyPlugin.Ilmerged', ключ маршрутизации: 'person.crm2015 .changed», идентификатор корреляции: «094fbde9-f7a3-4884-82d7-8a1792e38d6e»

Не объединено:

DEBUG: Объявлен Exchange: MyPluginCrmEntityChange:MyPlugin type:topic, durable:True, autoDelete:False, delayed:False DEBUG: Опубликовано для обмена: 'MyPlugin.CrmEntityChange:MyPlugin', ключ маршрутизации: 'person.crm2015.changed', коэффициент корреляции: 'e41b4360-04c8-4210-917a-17540d41f3ce'

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

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

person Dylan Beattie    schedule 31.07.2015