azure / azure-service-bus-dotnet

☁️ .NET Standard client library for Azure Service Bus

Microsoft Azure Service Bus Client for .NET

Azure Service Bus allows you to build applications that take advantage of asynchronous messaging patterns using a highly-reliable service to broker messages between producers and consumers. Azure Service Bus provides flexible, brokered messaging between client and server, along with structured first-in, first-out (FIFO) messaging, and publish/subscribe capabilities with complex routing.

This is the next generation Service Bus .NET client library focused on queues and topics. If you are looking for Event Hubs and Relay clients, please see:

• Event Hubs
• Relay

We've moved!

The Microsoft Azure Service Bus Client for .NET has joined the unified Azure Developer Platform and can now be found in the Azure SDK for .NET repository. To view the latest source, participate in the development process, report issues, or engage with the community, please visit our new home.

This repository has been archived and is intended to provide historical reference and context for the Microsoft Azure Service Bus Client for .NET

Source code | Package (NuGet) | API reference documentation | Product documentation

azure-service-bus-dotnet's Issues

Message scheduling and cancellation

I believe this is covered for "Sprint 5: Early 2017" but just checking in to see if this functionality is planned. I need functionality as discussed in Canceling Scheduled Messages and I assume the SequenceNumber property is not valid for using to cancel as suggested in the article.

Is the API for ScheduleMessageAsync and CancelScheduledMessageAsync expected to come under Sprint 5?

Thanks for the great work and looking forward to trying this out with .NET Core :)

Implement Abandon/Deadletter/Defer/RenewMessageLock

From @vinaysurya on October 12, 2016 2:2

Following API Constructs will need to be implemented for this task:
a) AbandonAsync(Guid LockToken) and AbandonAsync(Guid lockToken, IDictionary<string, object> propertiesToModify)
b) DeadletterAsync(Guid lockToken), DeadletterAsync(Guid lockToken, IDictionary<string, object> propertiesToModify) and DeadLetterAsync(Guid lockToken, string deadLetterReason, string deadLetterErrorDescription)
c) DeferAsync(Guid LockToken), DeferAsync(Guid lockToken, IDictionary<string, object> propertiesToModify) and Receive(BySequenceNumber)
d) RenewMessageLockAsync(Guid LockToken)

Copied from original issue: Azure/azure-messaging-dotnet#5

Implement Topic and Subscription Send/Receive and most of the Send/Receive/Batch for them

From @vinaysurya on October 12, 2016 2:9

Copied from original issue: Azure/azure-messaging-dotnet#7

Implement Sessions support() for Queues and Topics

From @vinaysurya on October 12, 2016 2:10

Copied from original issue: Azure/azure-messaging-dotnet#8

Review how Peek is working

There are 3 types of messages that can be found on a queue

1. Ready for processing
2. Delayed (ScheduleEnqueueTimeUtc set in future)
3. Deferred (only can be received by SequenceNumber)

When messages are enqueued in the future, they cannot be received.
When messages are peeked, future messages are fully returned (headers & body).
For scenarios when there are many future messages, peek becomes too heavy of an operation.

When peeking for messages, I should be able to choose what am I interested in. If I need to evaluate all, then current behavior is fine. But otherwise, I'm not sure the current behavior is good.

Question: Should the default behavior be only to return what's ready for processing?

An override could then return what's ready for processing and enqueued for the future.

Note: this potentially might require some changed on the broker side. I'll raise a separate issue for that.

Implement PeekLock Semantics and CompleteAsync(Guid LockToken) calls

From @vinaysurya on October 10, 2016 18:19

Copied from original issue: Azure/azure-messaging-dotnet#1

Implement PartitionedEntitySupport for perf

From @vinaysurya on October 12, 2016 2:13

Copied from original issue: Azure/azure-messaging-dotnet#12

Prefix environment variables with project specific identifier

Given that one can work on multiple projects that require environment variable, would be nice to have env variables that are easier to identify. This is my environment variables (not the full list) and ASB client project`s env variable is just lost.

What if ConnectionStringEnvironmentVariable
would be azure-service-bus-dotnet/ConnectionString?

In addition to that, the EnvironmentVariable suffix for an environment variable is not needed. Save bytes, save the world.

Correction

Environment variable is called SERVICEBUSCONNECTIONSTRING. Exception thrown is PR #41 is misleading. Proposal is still valid. Instead of SERVICEBUSCONNECTIONSTRING call it azure-service-bus-dotnet/ConnectionString.

PR builds do not log (execute?) tests

Expected Behavior

To see test results

Actual Behavior

The build job has not produced any test results.

Example: sample output

Implement Batching Support for APIs

From @vinaysurya on October 12, 2016 2:4

Will need to implement the following APIs:
a) SendBatch(SendBatchByCount)
b) ReceiveBatch(ReceiveBatchByMessageCount, ReceiveBatchBySequenceNumbers, ReceiveBatchWithServerWaitTime)

Copied from original issue: Azure/azure-messaging-dotnet#6

Public API documentation

Should this be covered by stylecop @jtaubensee?

Simplify BrokeredMessage Class to remove unnecessary Streams and BufferManagers

From @vinaysurya on October 10, 2016 18:27

Copied from original issue: Azure/azure-messaging-dotnet#3

Suggestion: a separate GH repo for ASB server side issues

This repository is designated for the client.
There's no repository (for now) for the broker (server) side issues.
While there's a UserVoice forum, it is abandoned and doesn't serve its purpose as well as GH does.

I suggest to open a separate GH repo for the ASB server side for issues. It will allow tracking/reporting/linking/notification the way developers are accustomed to interact.

Additionally, it will help to connect client issues with server side issues (such as #89 and #46).

Add Browse/Peek support

From @vinaysurya on October 12, 2016 2:11

Copied from original issue: Azure/azure-messaging-dotnet#9

Update Projects to VS2017

Actual Behavior

1. Projects use project.json

Expected Behavior

1. Projects use .csproj

Versions

• OS platform and version:
• .NET Version:
• NuGet package version or commit ID:

Ability to purge a queue

There are scenarios where purging a queue is necessary

• Testing scenarios
• Removing all messages because they are no longer needed
• Clearing out deferred messages when sequence numbers are no longer retained by an app

Similar functionality: ASQ`s CloudQueue.ClearAsync().

This would apply to both queue/subscription and associated DLQs.

Unexpected default behavior of QueueClient.OnMessage (ReceiveAndDelete instead of PeekLock)

Preamble

ClientQueue has a property Mode of type ReceiveMode:

public enum ReceiveMode
 {
    // Specifies the PeekLock receive mode.
    // This is the default value for Microsoft.ServiceBus.Messaging.ReceiveMode.
    PeekLock = 0,
    // Specifies the ReceiveAndDelete receive mode.
    ReceiveAndDelete = 1
}

and the PeekLock mode is indeed the default mode when requesting a message from the client, i.e. with something like this (from the Apps that use queues example):

MessageReceiver receiver = factory.CreateMessageReceiver("DataCollectionQueue");
BrokeredMessage receivedMessage = receiver.Receive();
try
{
    ProcessMessage(receivedMessage);
    receivedMessage.Complete();
}
catch (Exception e)
{
    receivedMessage.Abandon();
}

Issue

When using QueueClient.OnMessage(Action<BrokeredMessage> callback) to subscribe to the queue, things work differently than expected, and the ClientQueue.Mode property is ignored and the default behavior is the ReceiveAndDelete.

This is undocumented, as far as I have seen, and the only example of OnMessage usage in the documentation simply omit the Complete() method invocation without explaining why.

The only way to have the PeekLock behavior with OnMessage is to explicitly declare AutoComplete = false in the OnMessageOptions:

Client.OnMessage((receivedMessage) =>
{
    try
    {
        // Process the message
        receivedMessage.Complete();
    }
    catch (Exception e)
    {
        // Handle any message processing specific exceptions here
        receivedMessage.Abbandon();
    }
}, new OnMessageOptions() { AutoComplete = false });

Conclusions

I understand that this is not a bug but an unexpected default behavior.
Is unexpected because:

• everywhere in the documentation is stated that the default behavior is the PeekLock mode.
• the OnMessage ignore the value of the ClientQueue.Mode property in favor of the OnMessageOptions.AutoComplete property.

Suggested action

I also understand that changing the default OnMessageOptions.AutoComplete value to false could produce breaking changes on code actually in production, so my only request is to stress this issue in the documentation clearly stating that the default behavior of OnMessage is the ReceiveAndDelete mode .

UPDATE:

Please see the comment following the reopened action, that is related to this repo, where I ask for a change of the default behavior and I propose the code changes, based on the fact that this is a new library, still in preview.

OnSession Handler

@vinaysurya to provide details

OnMessage Graceful Client Shutdown

This is a reminder to add functionality to provide a graceful client shutdown. In the full .NET client, when Close is called, a message can still be pushed to OnMessage.

Create NuGet Package

Though I hate to mention it under issues, but this is the only place I found.
I think we should now have a pre-release nuget package for it. That way more real customers can try it and you can get more feedback.

Path and Name confusion

This is more of a question/discussion issue.
With the old client, there was somewhat of a confusion around Path and Name.

Queues

this/is/a/queue
path: this/is/a/queue

Topics

a/b/c
path: a/b/c

Subscription

some/topic/subscriptions/sub
topic path: some/topic
name: sub

While queues and topics share a common Path concept, they are not consistent with subscriptions. Would it helpful to have a FullPath abstraction that would be available for all 3 entity types?

Queues: FullPath == Path
Topics: FullPath == Path
Subscriptions: FullPath == TopicPath/subscriptions/Name

Change MessagingEntityType to internal

Traditionally, this was limited to 4 entity types

1. Queue
2. Topic
3. Subscription
4. Filter

Entities would reside under Namespace.

With the new client, MessagingEntityType is adding Namespace as an entity. Is namespace truly an entity? Are different concerns mixed together?

StyleCop as a Roslyn analyzer

Let's use Roslyn analyzer for StyleCop rather than a VS addon.
Benefits are:

1. Baked into the project
2. Doesn't require to remember to run it

Here's a link: https://github.com/DotNetAnalyzers/StyleCopAnalyzers

Enable Queue Basic Send/Receive

From @vinaysurya on October 10, 2016 18:26

Copied from original issue: Azure/azure-messaging-dotnet#2

Can't use MessageSender & MessageReceiver

Expected Behavior

Use MessageSender and MessageReceiver to send/receive messages.

Actual Behavior

Classes are abstract and cannot be used.

Version: current master
Commit: a34fbdb

Change Message.Body type to byte[]

Actual Behavior

• In the .NET framework client a BrokeredMessage can be a serialize-able object, or a stream.

Expected Behavior

• Change Message to only support byte[]
• We are proposing that the Message class be closely related to the Event Hubs EventData class

Why

• The use of streams makes extensibility much more difficult. The Message class is already a heavier object than it needs to be, and a majority of the logic in the class is around stream handling. For instance, if we want to make a handle to manipulate the Message.Body when sending or receiving a message, we need to be able to handle multiple streams, and "resetting" the body. This proposal would allow you to simply call something like: message.Body = new byte[]();
• Passing streams to Service Bus can result in a blocking send. For example, if you send a message with a stream and call send, the entire stream needs to be read (from where ever it is) into memory before the actual send occurs. This can cause users to think that there is an issue with Service Bus performance, when that is not actually the case.

Edit:

Pointed out by @SeanFeldman, this also means that we would remove the DataContractSerializer pieces as well.

Remove solution folders for test & src from solution in VS

This is what it currently looks like

Each time navigation to the source or test project requires unnecessary expansion of the src and test solution folders. While it's ok to keep things separated on the file system, is there a real need for this in a VS solution?

Suggest to remove those solution folders in VS (keep it on the file system). That way loading solution will present the projects right away.

Public API validation

Related to #39

Minimal public API surface area validation should be automated to ensure that no internal types leaked out.
Suggest we look into API Approver to control the public API surface area, when API Approver supports .NET Standard.

/cc @jtaubensee

Add Transaction Semantics

From @vinaysurya on October 12, 2016 2:12

Copied from original issue: Azure/azure-messaging-dotnet#10

Abstracting common components for easier testing

There are scenarios where it would help to be able to test code that relies on ASB client w/o exercising ASB client itself. A few scenarios are:

• Broker not available
• Emulating certain operations to throw exceptions they can raise, but not on demand

With previous client the only option is to wrap everything from ASB to allow mocks/stubs. It would help to have new client to take testability into consideration.

Enable Topic Basic Send/Receive with PeekLock

From @vinaysurya on October 10, 2016 19:8

Copied from original issue: Azure/azure-messaging-dotnet#4

Failing CI / Unit Tests

These tests are currently failing in AppVeyor:

• .NET Core:
  • QueueClientTests.BasicRenewLockTest("non-partitioned-queue")
  • QueueClientTests.BasicRenewLockTest("partitioned-queue")
  • QueueClientTests.PeekLockDeferTest("partitioned-queue")
  • TopicClientTests.TopicClientRenewLockTestCase("non-partitioned-topic")
  • TopicClientTests.TopicClientRenewLockTestCase("partitioned-topic")
  • TopicClientTests.TopicClientPeekLockDeferTestCase("non-partitioned-topic")
  • TopicClientTests.TopicClientPeekLockWithAbandonTestCase("partitioned-topic")
• .NET 4.5.1
  • QueueClientTests.PeekLockWithAbandonTest("non-partitioned-queue")
  • QueueClientTests.PeekLockWithAbandonTest("partitioned-queue")
  • QueueClientTests.PeekLockDeferTest("partitioned-queue")
  • TopicClientTests.TopicClientPeekLockWithAbandonTestCase("non-partitioned-topic")

Here are the details of the tests: https://ci.appveyor.com/project/jtaubensee/azure-service-bus-dotnet/build/1.0.79/tests

Readme.md should provide local setup instructions

Instructions should contain prerequisites to set the project up locally.

• Environment variables needed to run tests
• Entities requires for the tests to run
• etc

Update OpenCover version for build

Not a must-have, but nice to visualize what is being tested (or not).

A tool such as https://codecov.io/ could help to visualize test coverage (supports XUnit and AppVeyor used by this project).

Running test suite as a whole fails

Using latest master branch I am not able to run the entire test suite.

XUnit test runner result:

Peeked messages:

I've modified the label of the sent messages to see what tests are causing messages to remain on the queue and see that those are the deferred messages that never get cleaned up:

Also couldn't receive and delete all the messages. Some are stack in the queue and have to remove the queue.

Questions

1. Is MessageId nil a normal thing? I was pretty sure MessageId should be always set to a value. Please educate me. (Separate issue #19)
2. Should tests always run with a clean slate and not leave "garbage" behind? With deferred messages it's not possible, they will be piling up. (potentially a separate issue /cc @jtaubensee)
3. Executing individual tests results should not be different from executing the entire suite. Once build server is in place, this will start hindering the work flow. Should we address it sooner than later? (potentially a separate issue /cc @jtaubensee)

Add transaction support for sessions/messaging

Actual Behavior

System.Transactions is not present in dotnet core and hence the service bus dotnet core client does not support transactions.

Expected Behavior

We would have some counterpart for System.Transactions.Transaction in the dotnet core world.

Versions

All

Reevaluate returning List<T> instead of IList<T>

Similar to

https://github.com/dotnet/coreclr/issues/1579
dotnet/coreclr#4468

Could you reevaluate the usage of IList on the APIs called on the hot path? For example in MessageReceiver.OnReceiveAsync(int maxMessageCount) you could directly return List<BrokeredMessage>. There is no value in abstracting it, not even for inheritors.

Please also consider where you know the message count or the amount of messages that the client wants to fetch to preallocate the lists with that count for better perf.

https://github.com/danielmarbach/MicroBenchmarks/blob/master/MicroBenchmarks/Linq/EnumerableVsList.cs

As you can see the interface dispatch and the GC overhead can mean a lot when you are receiving multiple messages

Happy to provide a PR if you agree.

Extend API for BrokeredMessage: IsReceived bool property

The BrokeredMessage API is problematic in the sense that there are several public properties that may throw exceptions, when attempting to read them. This includes all the properties that are only available for a BrokeredMessage that has been sent by Service Bus.

Scenario

I am currently attempting to write a generic WebAPI MediaTypeFormatter for BrokeredMessage. With the current API, this leads to ugly code:

public static bool IsReceived(BrokeredMessage message)
{
    try
    {
        int dummy = message.DeliveryCount;
        return true;
    }
    catch (InvalidOperationException)
    {
        return false;
    }
}

API proposal

I propose to add a new property:

bool IsReceived { get; }

The definition would be: IsReceived will return true if and only if ThrowIfNotReceived does not throw. Or by the current implementation, if receiverHeaders != null.

OnMessage Handler

@vinaysurya to provide more details

UWP Support

Despite being a .NET Standard 1.3 library, it doesn't currently work on UWP due to the dependency on System.Reflection.Emit. Not all libraries (outside of the NETStandard.Library) necessarily support all plaforms and RefEmit has never been supported on Store/UWP apps.

If you need this as an optimization, can you please cross-compile to a uap10.0 target that has an alternative?

FWIW, using VS 2017 and the new .NET Core CSProj format, you can easily multi-target to all platforms, including UWP:
https://github.com/Reactive-Extensions/Rx.NET/blob/15cc575c2ccd5f650ed392b3a22f6b122b436110/Rx.NET/Source/System.Reactive/System.Reactive.csproj#L2-L32

Newly constructed BrokeredMessage has MessageId set to null

When creating an instance of a BrokeredMessage, the MessageId should be assigned a unique value.
Currently, it's set to null.

This is breaking/deviating behavior from the current ASB client.

Update
After discussing this, the consensus is to allow message Id generator and a way to opt in.

Namespace name in the OnMessage exception handler

Creating a new issue from part of #34.

Verbatim from @SeanFeldman:

When OnMessageOptions.ExceptionReceived event handler is invoked, it doesn't provide information on what namespace it's using. Having that information in the new client implementation would help for custom fail-over implementation.

Role of BrokeredMessage.version

This is more of a questions than an issue.
What's the role of the BrokeredMessage.version and how is it supposed to be used?

Azure.Amqp vs AMQP.Net Lite

Currently the project is using Azure.Amqp (repo) that doesn't support TPL. There's a AMQP.Net Lite package that supports netstandard1.3.
Should AMQP.Net Lite be prefered?

More control over abandoned messages

Hi all,

Sometimes business logic decides that it would be good to retry a message at some latter time.
For this reason it would be very helpful, if Abandon(IDictionary<>) or similar, would be able to set ScheduledEnqueueTimeUtc.

msg.Abandon(new Dictionary<string, object>()
{
  { "ScheduledEnqueueTimeUtc", DateTime.Now.ToUniversalTime().AddMinutes(2) }
});

Right now, this does not work, because only custom properties can be manipulated this way.
I’m also happy to hear if this kind of retry can be achieved on some other easier way?
Right now, I typically set LockDuration on some reasonable retry time and avoid invoking of abandon in PeekLock mode. Another way is Deferring, but I don’t like it, because it requires me
track deferred message, which makes things more complicate then necessary.

To recap all, wouldn’t be good to have something between Deferr() and Abandon()?
For example Defer(TimeSpan) or Defer(ScheduleteTimeUtc) or Abandon(TimeSpan) or Abandn(TimeSpan)?!
Only difference would be, that in a case of Defer, property DeliveryCount wouldn’t be incremented.

Regards
Damir

Add appropriate Retry policies

From @vinaysurya on October 12, 2016 2:13

Copied from original issue: Azure/azure-messaging-dotnet#11

Error MSB4025 when deploying ASP.Net MVC .Net Core app

I am trying to deploy an ASP.Net MVC .Net Core app that was created on an Ubuntu 16.04 system in Visual Studio Code. When attempting to push local git deployment to my Azure app to its Azure App Service.
In the project’s root directory, I ran the following:
git push -u azure master
and got the following:

D:\home\site\repository\project.json(1,1): error MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 1, position 1.
remote: Failed exitCode=1, command=dotnet publish "project.json" --output "D:\local\Temp\8d436b77fda50dd" --configuration Release
remote: An error has occurred during web site deployment.
remote:
remote: Error - Changes committed to remote repository but deployment to website failed.
To https://[email protected]:443/mayappname.git
[new branch] master -> master
Branch master set up to track remote branch master from azure.

I got an almost identical error message when deploying from the identical repo on Bitbucket.

I have found references to this error when dealing with continuous integration paltforms but has anyone else seen this when trying to deploy an ASP.Net MVC .Net Core app? Here is the project.json file:

{
  "dependencies": {
    "Microsoft.NETCore.App": {
      "version": "1.1.0",
      "type": "platform"
    },
    "Microsoft.EntityFrameworkCore": "1.1.*",
    "Microsoft.AspNetCore.Diagnostics": "1.1.0",
    "Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore": "1.0.0",
    "Microsoft.AspNetCore.Mvc": "1.1.0",
    "Microsoft.EntityFrameworkCore.SqlServer":"1.1.*",
    "Microsoft.AspNetCore.Razor.Tools": {
      "version": "1.1.0-preview4-final",
      "type": "build"
    },
    "Microsoft.AspNetCore.Routing": "1.1.0",
    "Microsoft.AspNetCore.Server.IISIntegration": "1.1.0",
    "Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
    "Microsoft.AspNetCore.StaticFiles": "1.1.0",
    "Microsoft.Extensions.Configuration.EnvironmentVariables": "1.1.0",
    "Microsoft.Extensions.Configuration.Json": "1.1.0",
    "Microsoft.Extensions.Configuration.CommandLine": "1.1.0",
    "Microsoft.Extensions.Logging": "1.1.0",
    "Microsoft.Extensions.Logging.Console": "1.1.0",
    "Microsoft.Extensions.Logging.Debug": "1.1.0",
    "Microsoft.Extensions.Options.ConfigurationExtensions": "1.1.0",
    "Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.1.0"
  },

  "tools": {
    "BundlerMinifier.Core": "2.2.306",
    "Microsoft.AspNetCore.Razor.Tools": "1.1.0-preview4-final",
    "Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.1.0-preview4-final",
     "Microsoft.EntityFrameworkCore.Tools": {
      "version": "1.1.0-preview4-final",
      "imports": [
        "portable-net45+win8+dnxcore50",
        "portable-net45+win8"
      ]
    }
  },

  "frameworks": {
    "netcoreapp1.1": {
      "imports": [
        "dotnet5.6",
        "portable-net45+win8"
      ]
    }
  },

  "buildOptions": {
    "emitEntryPoint": true,
    "preserveCompilationContext": true
  },

  "runtimeOptions": {
    "configProperties": {
      "System.GC.Server": true
    }
  },

  "publishOptions": {
    "include": [
      "wwwroot",
      "**/*.cshtml",
      "appsettings.json",
      "web.config"
    ]
  },

  "scripts": {
    "precompile": [ "dotnet bundle" ],
    "prepublish": [ "bower install" ],
    "postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]
  },

  "tooling": {
    "defaultNamespace": "myNameSpace"
  }
}

I have created a public repo here: https://github.com/m2web/m2prayer.net.core.public
To date there is little available concerning the error that I am getting with asp.net core with Azure App Services.

Enable Topic Basic Send/Receive with PeekLock

From @vinaysurya on October 10, 2016 19:8

Copied from original issue: Azure/azure-messaging-dotnet#4

Simple vs. advanced API set

Created a new issue from #57.

Since this is a new client, our team has taken some time to reevaluate the current usage of our past library, and we want to make this new one as simple as possible. In order to do so, we are planning to use clients (i.e. Queue, Topic, Subscription) for general messaging scenarios, while using message senders/receivers for more advanced scenarios. As such we are proposing the following:

• Keep clients in the root namespace, and move sender/receivers to a separate namespace. We would like to keep the root namespace as simple as possible, allowing new customers to get started quickly without the need to learn too many concepts.
• Limit clients to a message pump model (i.e. OnMessage), and reserve direct receive calls for the MessageReceiver.
• Remove static create methods from the clients, and instantiate them through constructors.
• Some sort of connection pooling for clients, and allow customers to implement their own pooling algorithms for senders/receivers (this would come much later though).

After some initial investigation, the QueueClient interface can look something like this:

    public interface IQueueClient
    {
        public IQueueClient(string connectionString, ReceiveMode mode);   
        public string QueueName;
        public ReceiveMode Mode;
        public int PrefetchCount;    
        public Task CloseAsync();
        public Task SendAsync(BrokeredMessage message);
        public Task SendAsync(IList<BrokeredMessage> messages);
        public Task CompleteAsync(Guid lockToken);
        public Task AbandonAsync(Guid lockToken);
        public Task DeferAsync(Guid lockToken);
        public Task DeadLetterAsync(Guid lockToken);
        public Task<long> ScheduleMessageAsync(Message message, DateTimeOffset scheduledEnqueueTimeUtc);
        public Task CancelScheduledMessageAsync(long sequenceNumber);
        public void RegisterMessageHandler(OnMessageOptions options, Func<BrokeredMessage, Task>);
        public void RegisterSessionHandler(OnSessionOptions options, Func<Session, Task>);
    }

Other functionality that exisits in the .NET API today, that is not in the QueueClient above would then live in either MessageSender or MessageReceiver.

Management Operations

In .Net we had a NamespaceManager and we could do things like:

if (!NamespaceManager.QueueExists(_commandQueueName))
{
    NamespaceManager.CreateQueue(_commandQueueName);
}

How can we do it with this .Net Standard library?