Я полагаю, что сериализатор указан на конечной точке, поэтому все сообщения, использующие эту конечную точку, будут использовать один и тот же сериализатор.
Тем не менее, если вы будете следовать зарекомендовавшей рекомендации NServiceBus одного типа сообщения на конечную точку / очередь, тогда вы сможете эффективно изолировать один тип сообщения и использовать для него другой сериализатор.
Мне любопытно, однако, что особенного в одном типе сообщения, который требует двоичной сериализации?
Редактировать в ответ на комментарий
Информация о распространителе косвенно упоминает об этом в разделе Маршрутизация с распространителем. Уди Дахан также часто советует это в NServiceBus Yahoo Group , хотя ссылки трудно предоставить, потому что поиск там плохой.
По сути, идея заключается в том, что вы не хотите, чтобы сообщения с высоким приоритетом застревали за сообщениями с более низким приоритетом, а также что это обеспечивает вам максимальную гибкость для масштабирования обработки определенных сообщений при необходимости.
Поскольку MsmqTransportConfig допускает указание только одного InputQueue, наличие одного типа сообщения на очередь также означает, что у вас есть только один обработчик сообщений на конечную точку.
Чтобы обратиться к изображению, вы все равно сможете инкапсулировать его в сообщение в формате XML, если закодируете байтовый массив как строку в кодировке Base64. Это не идеально, но если ваши изображения не слишком большие, это может быть легче сделать, чем использовать другой сериализатор только для одного типа сообщений.
Другой вариант - сохранить данные изображения вне диапазона в базе данных или файловой системе и затем обращаться к ним по идентификатору или пути (соответственно).