Michael Denny

@tmschlot can you please be so kind to provide us a sample to reproduce the problem? @thtp can you do the same with your use case?

I think we have to leverage `gitversion` to calculate the version, and there's a couple of ways with `gitversion`: - let `gitversion` calculate the version from branch names / commit...

@axelbodo I'm moving the conversation in a separated issue

At the moment easynetq does not re-declare exchanges when **PUBLISH** because is using an internal cache mechanism to avoid re-declaring exchange every call (see [`PublishExchangeDeclareStrategy`](https://github.com/EasyNetQ/EasyNetQ/blob/master/Source/EasyNetQ/Producer/PublishExchangeDeclareStrategy.cs)). As far as I understood...

on consumer side you need to check the re-connecting process, it is re-issued the consume command but not the re-declare, and probably we can add it if it fits in...

> For rpc request queues, which are not exclusive, I think the best approach is to push down queue declaration into PersistentConsumer.StartConsuming, by propagating the queue declaration properties in Queue...

Actually the wiki is wrong, at least nowadays, I never saw that behavior, is it correct to say that caches the subscription, but I never saw you can subscribe if...

> If we catch an exception ... we go through the queue and try the subscriptions again. what if the exception is thrown by rabbitmq because of mismatch queue parameters...

> I guess there is no way of knowing at runtime whether it's a queue mismatch or rabbit is down? I think it is possible, rabbitmq throw specific error on...

**EDIT** ~~Another hint, if we enable RetryOnFirstConnection then LazySubscribe should be forced on. Viceversa you can disable RetryOnFirstConnection and have LazySubscribe on or off as you wish.~~