Sdk migration ServiceBus Queues

[Merlijnv]

To make #607 possible we need to migrate the sdk's for servicebus, notificationhub and such to the new sdk.
To make this possible I am going to start with servicebus queues

[Merlijnv]

@SeanFeldman the PR you asked for so that the issue is not filled with discussions about the implementatie and such

[SeanFeldman]

(I've marked the PR as a draft PR)

@Merlijnv, you're doing great 👍

Feel free to adopt or discard: you could go for a Centralized Package Management. Easier to control the versions required by projects.

[Merlijnv]

@SeanFeldman previous QueueDescription seems to be splitted up into 2 (QueueProperties and QueueRuntimeProperties) So I have to or choose 1 to use or retrieve both. What is your opinion on this?

[SeanFeldman]

@SeanFeldman previous QueueDescription seems to be splitted up into 2 (QueueProperties and QueueRuntimeProperties) So I have to or choose 1 to use or retrieve both. What is your opinion on this?

Not following.

• QueueProperties is necessary to provide the information about the queue and to be able to modify those.
• QueueRuntimeProperties is for the message counts.

You'll need both. If you want, you could introduce an abstraction, QueueProperties that would expose the information from the two new APIs.

[Merlijnv]

Not following.

* `QueueProperties` is necessary to provide the information about the queue and to be able to modify those.

* `QueueRuntimeProperties` is for the message counts.

Yeah but for example for the queue overview I only need QueueRuntimeProperties because that includes all the info for it.
So I was thinking or always combine and have some extra info but also extra possible unneeded call. Or make seperate calls for if both, Properties or RuntimeProperties are needed. Idk what would be the impact of always using a combined call.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.