whitespace

nservicebus/azure-service-bus/configuration/full.md

@@ -13,10 +13,10 @@ redirects:
 ## Full Configuration API
 
 The full configuration API can be accessed from the `UseTransport<AzureServiceBusTransport>()` extension method and provides low level access to various aspects of the transport's behavior.
- 
+
 
 ## Configuring The Topology
- 
+
 A topology defines what the underlying layout of Azure Service Bus messaging entities looks like, specifically what entities are used and how they relate to each other. There are 2 built-in topologies: `EndpointOrientedTopology` and `ForwardingTopology`. For more information refer to the [Topologies](/nservicebus/azure-service-bus/topologies) article.
 
  * `UseTopology<T>()`: Specifies which topology should be used by the transport, instantiating it using the default constructor.
@@ -31,7 +31,7 @@ The [Forwarding Topology](/nservicebus/azure-service-bus/topologies/#version-7-a
  * `NumberOfEntitiesInBundle(int)`: The number of topics in the bundle, defaults to 2.
  * `BundlePrefix(string)`: The prefix used in the entity name to differentiate entities from the bundle from other entities.
 
- 
+
 ### Endpoint Oriented Topology
 
 The [Endpoint Oriented Topology](/nservicebus/azure-service-bus/topologies/#version-7-and-above-endpoint-oriented-topology) defines a queue and a topic per endpoint. It can be configured using the following settings:
@@ -42,7 +42,7 @@ The [Endpoint Oriented Topology](/nservicebus/azure-service-bus/topologies/#vers
 
 ## Controlling Entities
 
-The topology will create entities it needs, based on the following settings: 
+The topology will create entities it needs, based on the following settings:
 
  * `Queues()`: Settings for queues.
  * `Topics()`: Settings for topics.
@@ -72,7 +72,7 @@ The following settings are available to define how queues should be created:
 
 
 ### Topics
- 
+
 The following settings are available to define how topics should be created:
 
  * `MaxSizeInMegabytes(SizeInMegabytes)`: The size of the topic, in megabytes. Defaults to 1,024 MB.
@@ -92,7 +92,7 @@ The following settings are available to define how topics should be created:
 ### Subscriptions
 
 The following settings are available to define how subscriptions should be created:
- 
+
  * `DefaultMessageTimeToLive(TimeSpan)`: The maximum age of a message, defaults to `TimeSpan.MaxValue`.
  * `EnableBatchedOperations(bool)`: Enables server side batched operations, defaults to `true`.
  * `EnableDeadLetteringOnFilterEvaluationExceptions(bool)`: Dead letters messages when a filter evaluation doesn't match, defaults to `false`.
@@ -103,12 +103,12 @@ The following settings are available to define how subscriptions should be creat
  * `MaxDeliveryCount(int)`: Sets the maximum delivery count, defaults to 10.
  * `AutoDeleteOnIdle(TimeSpan)`: Automatically deletes the subscription if it hasn't been used for the specified time period. By default the subscription will not be automatically deleted.
  * `DescriptionFactory(Func<string, string, ReadOnlySettings, SubscriptionDescription>)`: A factory method that allows to create a `SubscriptionDescription` object from the Azure Service Bus SDK. Use this factory method to override any (future) setting that is not supported by the Subscription API.
- 
+
 
 ## Controlling Connectivity
 
 The following settings determine how NServiceBus will connect to Azure Service Bus:
- 
+
  * `NumberOfClientsPerEntity(int)`: NServiceBus maintains a pool of receive and send clients for each entity. This setting determines how big that pool is. Defaults to 5.
  * `ConnectivityMode(ConnectivityMode)`: Determines how NServiceBus connects to Azure Service Bus, using TCP or HTTP. Defaults to TCP.
  * `BrokeredMessageBodyType(SupportedBrokeredMessageBodyTypes)`: Controls how the body of a brokered message will be serialized, either as a byte array or as a stream. Defaults to byte array.
@@ -127,7 +127,7 @@ The following settings allow to control the messaging factories:
  * `RetryPolicy(RetryPolicy)`: Determines how entities should respond on transient connectivity failures. Defaults to `RetryPolicy.Default`, which is an exponential retry.
  * `BatchFlushInterval(TimeSpan)`: This setting controls the batching behavior for message senders. They will buffer send operations during this time frame and send all messages at once. Defaults to 0.5 seconds. Specify `TimeSpan.Zero` to turn batching off.
  * `MessagingFactorySettingsFactory(Func<string, MessagingFactorySettings>)`: This factory method allows to override creation of messaging factories.
- 
+
 
 ### Message Receivers
 
@@ -158,14 +158,14 @@ The Azure Service Bus transport can guarantee transactional behavior by combinin
  * The source and destination are in the same namespace,
  * Messages are received using `ReceiveMode.PeekLock` mode,
  * The transport explicitly sends messages via the receive queue.
- 
+
 Enable the latter using the following configuration setting:
 
  * `SendViaReceiveQueue(bool)`: Uses the receive queue to dispatch outgoing messages when possible. Defaults to `true`.
 
  To learn more about the supported transactional behaviors in the Azure Service Bus transport, refer to the [Transaction Support in Azure](/nservicebus/azure-service-bus/transaction-support.md) article.
 
-  
+
 ## Physical Addressing Logic
 
 One of the responsibilities of the transport is determining the names and physical location of the entities. It is achieved by turning logical endpoint names into physical addresses of the Azure Service Bus entities, which is called *Physical Addressing Logic*. The following configuration settings allow to redefine this aspect of the transport:
@@ -176,7 +176,7 @@ One of the responsibilities of the transport is determining the names and physic
  * `NamespacePartitioning()`: Provides access to the settings that determine how entities are partitioned across namespaces.
  * `Composition()`: Provides access to the settings that determine how entities are composed inside a single namespace.
 
- 
+
 ### Sanitization
 
 Sanitization refers to the cleanup logic that converts invalid entity names into valid ones. "Validation rules" are the individual logic blocks used to determine if entity names are valid. The rules implementations vary depending on the namespace type, and are changing over time (in some cases without notice and update of the [relevant MSDN documentation](https://azure.microsoft.com/en-us/documentation/articles/service-bus-quotas/)). The default settings align with the recently created Standard namespaces.
@@ -187,7 +187,7 @@ Sanitization refers to the cleanup logic that converts invalid entity names into
  * `UseRulePathMaximumLength(int)`: The maximum length of a rule path (path = name), defaults to 50.
  * `UseStrategy<T>()`: An implementation of `ISanitizationStrategy` that handles invalid entity names. The following implementations exist:
 	 * `ThrowOnFailedValidation`: (default) throws an exception if the name is invalid.
-	 * `ValidateAndHashIfNeeded`: allows customization of sanitization without creating a new strategy.  
+	 * `ValidateAndHashIfNeeded`: allows customization of sanitization without creating a new strategy.
 
 `UseStrategy<T>()` can be used to customize the selected [sanitization](/nservicebus/azure-service-bus/sanitization.md) strategy or completely replace it.
 
@@ -200,7 +200,7 @@ Individualization is the logic for modifying an entity name, to allow for differ
 	 * `CoreIndividualization` (default): Makes no modifications, and relies on the individualization logic as defined in the NServiceBus core framework.
 	 * `DiscriminatorBasedIndividualization`: modifies the name of the endpoint by appending a discriminator value to the end.
 
- 
+
 ### Namespace Partitioning
 
 The settings that determine how entities are partitioned across namespaces:

nservicebus/azure-service-bus/namespace-hierarchy.md

@@ -5,7 +5,7 @@ component: ASB
 tags:
 - Cloud
 - Azure
-- Transports 
+- Transports
 ---
 
 At the core of the Azure Service Bus service, there is a Service Registry which tracks the location of each queue, topic, relay or eventhub in the service. This Service Registry provides a DNS integrated hierarchical naming system, that has a root entry point (called a namespace) at a URI with the following scheme.

nservicebus/azure-service-bus/publisher-names-configuration.md

@@ -9,7 +9,7 @@ tags:
 reviewed: 2016-04-18
 ---
 
-When the [`EndpointOrientedTopology`](/nservicebus/azure-service-bus/topologies/#version-7-and-above-endpoint-oriented-topology) is selected, a mapping between publisher names and event types has to be properly configured, in order to ensure that subscriber can receive event messages.  
+When the [`EndpointOrientedTopology`](/nservicebus/azure-service-bus/topologies/#version-7-and-above-endpoint-oriented-topology) is selected, a mapping between publisher names and event types has to be properly configured, in order to ensure that subscriber can receive event messages. 
 
 The mapping can be configured for a specific event type:
 

nservicebus/azure-service-bus/securing-connection-strings.md

@@ -5,7 +5,7 @@ component: ASB
 tags:
 - Cloud
 - Azure
-- Transports 
+- Transports
 - Security
 reviewed: 2016-04-26
 related:

nservicebus/azure-service-bus/token-provider.md

@@ -5,8 +5,8 @@ component: ASB
 tags:
  - Cloud
  - Azure
- - Transports 
- - Security 
+ - Transports
+ - Security
 ---
 
 By default the Azure Service Bus transport authenticates to the service using the information embedded in the connection string. But it's also possible to let it authenticate using any of the authentication mechanisms supported by [Azure Service Bus](https://azure.microsoft.com/en-us/documentation/articles/service-bus-authentication-and-authorization/).

nservicebus/azure-storage-persistence/configuration.md

@@ -50,7 +50,7 @@ NOTE: Subscriptions and Timeouts persistence configurations have no effect when
 
 
 #### Saga Configuration
-  
+
 When using XML-based configuration, the following properties can be set through the `AzureSagaPersisterConfig` section:
 
  * `ConnectionString`: Sets the connectionstring for the storage account to be used for storing saga information.

nservicebus/azure-storage-queues/configuration.md

@@ -76,7 +76,7 @@ Note: All endpoints in the same system must use the same serializer for the mess
 The number of parallel receive operations that the transport is issuing against the storage queue to pull messages out of it.
 
 Defaults: In Versions 7 and above the value is dynamically calculated based on the endpoints [message processing concurrency limit](/nservicebus/operations/tuning.md), using the following equation:
- 
+
 `Degree of parallelism = square root of MaxConcurrency (rounded)`
 
 |`MaxConcurrency` | `DegreeOfReceiveParallelism` |

nservicebus/azure/transactions.md

@@ -120,7 +120,7 @@ In essence, using sagas is implementing a Distributed Transaction Coordinator th
  * Considering and implementing all possible variations and error conditions in a transaction is a non-trivial amount of work.
  * Effective implementation requires a good understanding of the business requirements. The implementation details are driven by business decisions more than technical considerations, so it's recommended to collaborate closely with business experts when designing sagas.
  * Sagas are stateful therefore the operation cannot be atomic. This needs to be taken into consideration when sagas are used in combination with atomic operations that cannot be batched. Operations against a Store should never be executed directly inside the saga itself. Instead, they should be executed by another handler and queued in between, to cater for idempotency at all levels.
- 
+
 
 ### Routing slips and compensation logic
 

nservicebus/endpoints/specify-endpoint-name.md

@@ -21,7 +21,7 @@ Define a convention in the endpoint initialization code using this:
 snippet:EndpointNameCode
 
 
-## When using the NServiceBus.Host.exe 
+## When using the NServiceBus.Host.exe
 
 
 ### Namespace convention

nservicebus/gateway/multi-site-deployments.md

@@ -55,7 +55,7 @@ This model is recommended as it provides all the benefits of durable messaging b
 
 In cases where only have access to HTTP for connection between sites, it is possible to enable the NServiceBus Gateway on each site so it transmits messages from a queue in one site to a queue in another site, including the hash of the messages to ensure that the message is transmitted correctly. The following diagram shows how it works:
 
-![Gateway Headquarter to Site A](gateway-headquarter-to-site-a.png) 
+![Gateway Headquarter to Site A](gateway-headquarter-to-site-a.png)
 
 The sending process in site A sends a message to the gateway's input queue. The gateway then initiates an HTTP connection to its configured target site. The gateway in site B accepts HTTP connections, takes the message transmitted, hashes it, and returns the hash to site A. If the hashes match, the gateway in site B transmits the message it receives to a configured queue. If the hashes don't match, the gateway in site A re-transmits.
 

nservicebus/gateway/troubleshooting.md

@@ -38,7 +38,7 @@ netsh http add urlacl url=YourUrl user="YourMachine\EndpointUsername"
 
 For example
 
-```dos 
+```dos
 netsh http delete urlacl http://localhost:25894/MyEndpoint/
 netsh http add urlacl url=http://localhost:25894/MyEndpoint/ user="Machine\MyEndpointServiceAccount"
 ```

nservicebus/handlers/async-handlers.md

@@ -18,7 +18,7 @@ WARNING: It is difficult to give generic advice how asynchronous code should be
 
 There are two thread pools. The worker thread pool and the IO thread pool.
 
-Further reading: 
+Further reading:
 
  * [Thread Pools](https://msdn.microsoft.com/en-us/library/windows/desktop/ms686760.aspx)
  * [Thread Pooling](https://msdn.microsoft.com/en-us/library/windows/desktop/ms686756.aspx)

nservicebus/hosting/nservicebus-host/logging-profiles.md

@@ -28,9 +28,9 @@ These profiles are only placeholders for logging customization. If no customizat
 
 The logging behavior configured for the three built-in profiles is shown:
 
-| Profile     | Appender     | Threshold 
+| Profile     | Appender     | Threshold
 |-------------|--------------|-----
-| Lite        | Console      | Info                        
+| Lite        | Console      | Info                       
 | Integration | Console      | Info
 | Production  | Rolling File | Info
 

nservicebus/hosting/nservicebus-host/profiles.md

@@ -90,7 +90,7 @@ Logging is another kind of behavior that can be changed from one profile to anot
 
 The logging behavior configured for the three built-in profiles is shown:
 
-| Profile     | Appender     | Threshold 
+| Profile     | Appender     | Threshold
 |-------------|--------------|-----
 | Lite        | Console      | Debug
 | Integration | Console      | Info
@@ -125,7 +125,7 @@ The following table summarizes the different persistence technologies being used
 NOTE: Before configuring persistence technology, to avoid overriding custom configurations, the profiles check if other types of storage are used.
 
 |-                                |In-Memory|RavenDB			   |NHibernate   |MSMQ                         |
-|:--------------------------------|:--------|:---------------------|:------------|:----------------------------|                                        
+|:--------------------------------|:--------|:---------------------|:------------|:----------------------------|                                       
 |  Timeout                        |Lite     |Integration/Production|-            |Keeps a queue for management |
 |  Subscription                   |Lite     |Integration/Production|-            |-                            |
 |  Saga                           |Lite     |Integration/Production|-            |-    				           |

nservicebus/hosting/web-application.md

@@ -4,7 +4,7 @@ summary: Hosting NServiceBus in a Web Site or Web Service
 reviewed: 2016-05-16
 tags:
 - Hosting
-- Web Site 
+- Web Site
 - Web Service
 related:
  - samples/web

nservicebus/licensing/license-management.md

@@ -34,7 +34,7 @@ For 64-bit operating systems the license is written to both the 32-bit and 64-bi
 These following instructions cover installing the license file without using NServiceBus PowerShell Module. These options give a bit more flexibility as they support storing the the license in `HKEY_CURRENT_USER`. If the licenses is stored in `HKEY_CURRENT_USER` it is only accessible to the current user.
 
 
-##### Using PowerShell Command Prompt 
+##### Using PowerShell Command Prompt
 
 * Open an administrative PowerShell prompt.
 * Change the current working directory to where the license.xml file is.

nservicebus/lifecycle/endpointstartandstop.md

@@ -17,7 +17,7 @@ NOTE: The endpoint instance keeps an internal list of instances which need to be
 
 ## Versions 6 and above
 
-The `IWantToRunWhenBusStartsAndStops` interface is no longer available.  
+The `IWantToRunWhenBusStartsAndStops` interface is no longer available. 
 
 When self-hosting, there are several options for equivalent behavior:
 

nservicebus/messaging/databus.md

@@ -110,7 +110,7 @@ So for example this path can be used in a Handler for a message containing datab
 
 snippet:HandlerThatCleansUpDatabus
 
- 
+
 ## Configuring AzureDataBus
 
 The following extension methods are available for changing the behavior of `AzureDataBus` defaults:

nservicebus/messaging/file-based-routing.md

@@ -58,7 +58,7 @@ The MSMQ routing file contains additional attribute `Machine` which is necessary
 snippet:Routing-FileBased-MSMQ
 
 
-### Broker transports 
+### Broker transports
 
 The routing file for a broker transport does not need the `Machine` attribute but may contain other attributed specific to the transport technology. It also does not need to include non-scaled-out endpoints because NServiceBus assumes there is a single default instance of each endpoint (unless otherwise specified).
 

nservicebus/messaging/headers.md

@@ -85,7 +85,7 @@ The `MessageId` that caused this message to be sent.
 
 Message intent can have one of the following values:
 
-|               |             | 
+|               |             |
 | ------------- |-------------|
 | Send |Regular point-to-point send. Note that messages sent to Error queue will also have a `Send` intent|
 | Publish |The message is an event that has been published and will be sent to all subscribers.|
@@ -254,7 +254,7 @@ The [host details](/nservicebus/hosting/override-hostid.md) of the endpoint wher
  * `$.diagnostics.hostdisplayname`
  * `$.diagnostics.hostid`
  * `$.diagnostics.originating.hostid`
- 
+
 
 ### NServiceBus.TimeSent
 

nservicebus/messaging/message-owner.md

@@ -92,7 +92,7 @@ To register all message types defined in an assembly with a specific namespace:
  * `Assembly` = `YourMessagesAssemblyName`
  * `Namespace` = `YourMessageNamespace`
  * `Endpoint` = `queue@machinename`
- 
+
 To register a specific type in an assembly:
 
  * `Assembly` = `YourMessagesAssemblyName`

nservicebus/messaging/publish-subscribe/index.md

@@ -62,7 +62,7 @@ The subscribe workflow for persistence based transports is as follows
  1. Subscribers request to a publisher the intent to subscribe to certain message types.
  1. Publisher stores both the subscriber names and the message types in the persistence.
 
-<!-- 
+<!--
 https://bramp.github.io/js-sequence-diagrams/
 Participant Subscriber1 As Subscriber1
 Participant Subscriber2 As Subscriber2
@@ -85,7 +85,7 @@ The publish workflow for persistence based transports is as follows
  1. Publisher queries the storage for a list of subscribers.
  1. Publisher loops through the list and sends a copy of that message to each subscriber.
 
-<!-- 
+<!--
 https://bramp.github.io/js-sequence-diagrams/
 Participant Subscriber1 As Subscriber1
 Participant Subscriber2 As Subscriber2
@@ -118,7 +118,7 @@ The subscribe workflow for native transports is as follows
 
 Note that in this case the publisher does not interact in the subscribe workflow.
 
-<!-- 
+<!--
 https://bramp.github.io/js-sequence-diagrams/
 Participant Subscriber1 As Subscriber1
 Participant Subscriber2 As Subscriber2
@@ -139,7 +139,7 @@ The publish workflow for native transports is as follows
  1. Publisher sends the message to the Broker.
  1. Broker sends a copy of that message to each subscriber.
 
-<!-- 
+<!--
 https://bramp.github.io/js-sequence-diagrams/
 Participant Subscriber1 As Subscriber1
 Participant Subscriber2 As Subscriber2

nservicebus/messaging/routing.md

@@ -110,7 +110,7 @@ Mapping a message type to the destination endpoint is the logical side of the ro
 
 #### Static routes
 
-The most common way of specifying the type mapping is through static routes. Most of the times the routing should specify the destination endpoint 
+The most common way of specifying the type mapping is through static routes. Most of the times the routing should specify the destination endpoint
 
 snippet:Routing-StaticRoutes-Endpoint
 

nservicebus/messaging/send-a-message.md

@@ -62,7 +62,7 @@ An endpoint can send a message to any of its instances:
 snippet:BasicSendToAnyInstance
 
 Or, it can request a message to be routed to itself, i.e. the same instance.
-NOTE: This option is only possible when endpoint instance ID has been specified 
+NOTE: This option is only possible when endpoint instance ID has been specified
 
 snippet:BasicSendToThisInstance