Migration from MQTTnet 3.1.2 (ManagedClient) to Version 5.x

[pivaeme]

I'm currently using MQTTnet and MQTTnet.Extensions.ManagedClient version 3.1.2, and the ManagedClient functionality covers all my business requirements. I now want to update to the latest versions.

I see that the last version with ManagedClient is 4.3.7.1207, and this functionality is not present in the 5.x branch. Since I rely heavily on ManagedClient, I have a few questions about how to proceed:

1. What is the recommended way to move from a project that depends on ManagedClient (like my v3.1.2 project) to version 5.x? I understand the functionality was removed, but what is the suggested alternative?

2. Does the recommendation for the 5.x branch mean that each developer should build their own management layer (handling reconnections, queues, etc.) on top of the standard MqttClient?

3. Are there any examples, common patterns shared by the community, or plans to bring back similar managed functionality in a future release?

4. From my starting point at v3.1.2, what is the most practical and stable path for an update?

5. Specifically, is updating directly from v3.1.2 to v4.3.7 (the last version with ManagedClient) considered a stable and straightforward process? Should I expect significant breaking changes?

6. If I choose to stay on v4.3.7, what are the main long-term trade-offs compared to being on v5.x? I am particularly interested in understanding what I might miss in terms of ongoing support, compatibility with future .NET versions, and security updates.

7. For clarity, I assume that using the core MQTTnet package v5.x together with the MQTTnet.Extensions.ManagedClient package v4.3.7 is not possible due to version locks and API differences. Can you confirm this and perhaps point out the main architectural changes that prevent such a mix?

[chkr1011]

1. The alternative is to use the regular client and build the features you need around it. If you check the code of version 3.x in the repo you will see that there is not much code required for auto reconnects etc.

2. Yes, probably there will be a fork of someone but it is way too much work to build is in this project because the MQTTv5 features like user properties send for QoS 2 packets, redirects to different servers, throttling of messages etc. require a lot of effort to be reasonably well exposed in a new managed client.

3. Not yet.

4. Going to the very latest available version. There is no "path" you need to take. But check the breaking changes first.

5. Version 4 will get updates from time to time and is still supported. But you will not get new features and performance/memory improvements.

6. The biggest downside is performance and memory consumption because version 5 started using Span/Memory etc. from the .NET Framework. Since we are also relying on .NET Sockets/WebSockets/SSL implementation you will stick to the features which are available in older frameworks. SSL for example exposes more configuration properties in version 5 than in 4.x.

7. No, that is not supported and will also not compile at all.