Merge pull request #123417 from Particular/identity_and_update_latest

Identity and update to latest NServiceBus

Author: Court72

articles/service-bus-messaging/build-message-driven-apps-nservicebus.md

@@ -32,10 +32,10 @@ The sample assumes you've [created an Azure Service Bus namespace](service-bus-q
     The following diagram, generated by [ServiceInsight](https://particular.net/serviceinsight), a visualization and debugging tool from Particular Software, shows the message flow:
 
     :::image type="content" source="./media/nservicebus/sequence-diagram.png" alt-text="Image showing the sequence diagram":::    
-1. Open `SendReceiveWithNservicebus.sln` in your favorite code editor (For example, Visual Studio 2019). 
+1. Open `SendReceiveWithNservicebus.sln` in your favorite code editor (For example, Visual Studio 2022). 
 1. Open `appsettings.json` in both the Receiver and Sender projects and set `AzureServiceBusConnectionString` to the connection string for your Azure Service Bus namespace.
-
-
+   - This can be found in the Azure portal under  **Service Bus Namespace** > **Settings** > **Shared access policies** > **RootManageSharedAccessKey** > **Primary Connection String** .
+   - The `AzureServiceBusTransport` also has a constructor that accepts a namespace and token credential, which in a production environment will be more secure, however for the purposes of this tutorial the shared access key connection string will be used.
 
 ## Define the shared message contracts
 
@@ -86,14 +86,15 @@ var host = Host.CreateDefaultBuilder(args)
         // Configure the NServiceBus endpoint
         var endpointConfiguration = new EndpointConfiguration("Sender");
 
-        var transport = endpointConfiguration.UseTransport<AzureServiceBusTransport>();
         var connectionString = context.Configuration.GetConnectionString("AzureServiceBusConnectionString");
-        transport.ConnectionString(connectionString);
+        // If token credentials are to be used, the overload constructor for AzureServiceBusTransport would be used here
+        var routing = endpointConfiguration.UseTransport(new AzureServiceBusTransport(connectionString));
+        endpointConfiguration.UseSerialization<SystemJsonSerializer>();
 
-        transport.Routing().RouteToEndpoint(typeof(Ping), "Receiver");
+        endpointConfiguration.AuditProcessedMessagesTo("audit");
+        routing.RouteToEndpoint(typeof(Ping), "Receiver");
 
         endpointConfiguration.EnableInstallers();
-        endpointConfiguration.AuditProcessedMessagesTo("audit");
 
         return endpointConfiguration;
     })
@@ -140,13 +141,11 @@ public class SenderWorker : BackgroundService
             var round = 0;
             while (!stoppingToken.IsCancellationRequested)
             {
-                await messageSession.Send(new Ping { Round = round++ })
-                    .ConfigureAwait(false);
+                await messageSession.Send(new Ping { Round = round++ });;
 
                 logger.LogInformation($"Message #{round}");
 
-                await Task.Delay(1_000, stoppingToken)
-                    .ConfigureAwait(false);
+                await Task.Delay(1_000, stoppingToken);
             }
         }
         catch (OperationCanceledException)
@@ -204,11 +203,10 @@ Let's ignore the commented code for now; we'll get back to it later when we talk
 
 The class implements `IHandleMessages<Ping>`, which defines one method: `Handle`. This interface tells NServiceBus that when the endpoint receives a message of type `Ping`, it should be processed by the `Handle` method in this handler. The `Handle` method takes the message itself as a parameter, and an `IMessageHandlerContext`, which allows further messaging operations, such as replying, sending commands, or publishing events.
 
-Our `PingHandler` is straightforward: when a `Ping` message is received, log the message details and reply back to the sender with a new `Pong` message.
+Our `PingHandler` is straightforward: when a `Ping` message is received, log the message details and reply back to the sender with a new `Pong` message, which is subsequently handled in the Sender's `PongHandler`.
 
 > [!NOTE]
 > In the Sender's configuration, you specified that `Ping` messages should be routed to the Receiver. NServiceBus adds metadata to the messages indicating, among other things, the origin of the message. This is why you don't need to specify any routing data for the `Pong` reply message; it's automatically routed back to its origin: the Sender.
->
 
 With the Sender and Receiver both properly configured, you can now run the solution.
 
@@ -301,21 +299,20 @@ Next, it's time to figure out where to deploy our solution in Azure.
 In this sample, the Sender and Receiver endpoints are configured to run as console applications. They can also be hosted in various Azure services including Azure Functions, Azure App Services, Azure Container Instances, Azure Kubernetes Services, and Azure VMs. For example, here's how the Sender endpoint can be configured to run as an Azure Function:
 
 ```csharp
-[assembly: FunctionsStartup(typeof(Startup))]
-[assembly: NServiceBusEndpointName("Sender")]
-
-public class Startup : FunctionsStartup
+[assembly: NServiceBusTriggerFunction("Sender")]
+public class Program
 {
-    public override void Configure(IFunctionsHostBuilder builder)
+    public static async Task Main()
     {
-        builder.UseNServiceBus(() =>
-        {
-            var configuration = new ServiceBusTriggeredEndpointConfiguration("Sender");
-            var transport = configuration.AdvancedConfiguration.Transport;
-            transport.Routing().RouteToEndpoint(typeof(Ping), "Receiver");
+        var host = new HostBuilder()
+            .ConfigureFunctionsWorkerDefaults()
+            .UseNServiceBus(configuration =>
+            {
+                configuration.Routing().RouteToEndpoint(typeof(Ping), "Receiver");
+            })
+            .Build();
 
-            return configuration;
-        });
+        await host.RunAsync();
     }
 }
 ```