Removes extra markdown (#6859)

* Removes extra markdown

* Update container-deprecation-notice.include.md

* Update multi-site-deployments.md

* Update timeout-manager_content_core_[,8).partial.md

* Update recoverability.md

* Update index.md

* Update routing_content_msmqtransport_[1,).partial.md

Author: tamararivera

architecture/consistency.md

@@ -45,7 +45,7 @@ Databases and queueing technologies may support atomic transactions for a single
 Distributed transactions span multiple technologies, such as a database and a message queue. On Windows, the [Distributed Transaction Coordinator (DTC)](https://en.wikipedia.org/wiki/Microsoft_Distributed_Transaction_Coordinator) coordinates distributed transactions across multiple compatible participants using a [two-phase commit protocol](https://en.wikipedia.org/wiki/Two-phase_commit_protocol). Each participant must explicitly support the two-phase commit protocol.
 
 > [!WARNING]
-> While traditional on-premises focused services like MSMQ or Microsoft SQL Server support DTC transactions, managed cloud services do not, and require other > strategies for achieving consistency between resources such as:
+> While traditional on-premises focused services like MSMQ or Microsoft SQL Server support DTC transactions, managed cloud services do not, and require other strategies for achieving consistency between resources such as:
 >
 > * The [outbox pattern](#transactions-outbox-pattern), which uses database capabilities to achieve atomic consistency for data and message operations
 > * [Stateful workflows](workflows.md), which supervise the successful completion of all involved resources and manage compensating actions to achieve eventual consistency.

architecture/recoverability.md

@@ -22,7 +22,7 @@ Transient failures are temporary and are not caused by errors in business logic.
 > [!NOTE]
 > The Particular Platform simplifies the handling of transient errors:
 >
-> - NServiceBus has [built-in support for immediate and delayed retries](/nservicebus/recoverability/) for all supported messaging technologies. The automated > retries behavior is highly customizable.
+> - NServiceBus has [built-in support for immediate and delayed retries](/nservicebus/recoverability/) for all supported messaging technologies. The automated retries behavior is highly customizable.
 > - ServicePulse shows [real-time metrics monitoring retries](/servicepulse/#real-time-monitoring) occuring in the system.
 
 
@@ -49,4 +49,4 @@ Once the root cause of a persistent error has been resolved, messages can be mov
 - Don't catch exceptions in business logic invoked by messages. With message-level recoverability mechanisms in place, exceptions thrown from business logic cause messages to be retried without additional error handling code, such as `try/catch` blocks or [Polly](https://github.com/App-vNext/Polly).
 - Configure and customize recoverability policies using the [dedicated NServiceBus configuration options](/nservicebus/recoverability/) to avoid leaking infrastructure-related issues into business logic.
 - Review [consistency strategies](/architecture/consistency.md) for guidance on dealing with consistency while re-running business logic during retries.
-- Don't build custom retry mechanisms. Building custom recoverability logic is risky and error-prone. The NServiceBus retry mechanisms are proven and thoroughly tested.
+- Don't build custom retry mechanisms. Building custom recoverability logic is risky and error-prone. The NServiceBus retry mechanisms are proven and thoroughly tested.

nservicebus/dependency-injection/container-deprecation-notice.include.md

@@ -1,6 +1,6 @@
 > [!WARNING]
-> Starting with NServiceBus version 7, the dependency injection container adapter packages are no longer required. NServiceBus directly supports the `Microsoft.Extensions.DependencyInjection` model and third party containers can be integrated using > the [NServiceBus.Extensions.DependencyInjection package](/nservicebus/dependency-injection/extensions-dependencyinjection.md) or via the [.NET Generic Host](https://docs.microsoft.com/en-us/dotnet/core/extensions/generic-host).
+> Starting with NServiceBus version 7, the dependency injection container adapter packages are no longer required. NServiceBus directly supports the `Microsoft.Extensions.DependencyInjection` model and third party containers can be integrated using the [NServiceBus.Extensions.DependencyInjection package](/nservicebus/dependency-injection/extensions-dependencyinjection.md) or via the [.NET Generic Host](https://docs.microsoft.com/en-us/dotnet/core/extensions/generic-host).
 >
 > In NServiceBus version 8, NServiceBus will no longer provide adapters for external dependency injection containers.
 >
-> Visit the [dependency injection upgrade guide](/nservicebus/upgrades/7to8/dependency-injection.md) for further information.
+> Visit the [dependency injection upgrade guide](/nservicebus/upgrades/7to8/dependency-injection.md) for further information.

nservicebus/gateway/multi-site-deployments.md

@@ -84,9 +84,9 @@ NServiceBus automatically sets the required headers to enable sending messages b
 > [!NOTE]
 > The gateway is opinionated. It considers cross-site interactions through it to be inside the boundaries of a logical service.
 >
-> This internal communication between logically connected, but separately deployed components is restricted to use send semantics. The gateway exposes this through > the `SendToSites()` method.
+> This internal communication between logically connected, but separately deployed components is restricted to use send semantics. The gateway exposes this through the `SendToSites()` method.
 >
-> Since publish/subscribe semantics are intended for communication between different logical services; the gateway does not support it. Publish/subscribe is fine > between the endpoints on the same site, however.
+> Since publish/subscribe semantics are intended for communication between different logical services; the gateway does not support it. Publish/subscribe is fine between the endpoints on the same site, however.
 >
 > In a scenario with multiple logical services deployed cross-site, run separate gateways for each one.
 

nservicebus/messaging/timeout-manager_content_core_[,8).partial.md

@@ -1,7 +1,7 @@
 > [!NOTE]
-> Duplicate timeouts can be dispatched if the transport and persistence do not support [TransactionScope mode](/transports/transactions.md#transactions-transaction-scope-distributed-transaction), or are configured not to use it. Scaled-out > environments, in particular, are vulnerable to duplicate timeouts. The receiving endpoint must account for this, for example with the [outbox](/nservicebus/outbox/) or another idempotent mechanism.
+> Duplicate timeouts can be dispatched if the transport and persistence do not support [TransactionScope mode](/transports/transactions.md#transactions-transaction-scope-distributed-transaction), or are configured not to use it. Scaled-out environments, in particular, are vulnerable to duplicate timeouts. The receiving endpoint must account for this, for example with the [outbox](/nservicebus/outbox/) or another idempotent mechanism.
 >
-> Exactly-once timeouts are possible with [MSMQ](/transports/msmq/) or [SQL](/transports/sql/) transports with [NHibernate](/persistence/nhibernate/) or [SQL](/persistence/sql/) persistence **and** if they are configured to share the transactional > context (either through distributed transactions or connection sharing).
+> Exactly-once timeouts are possible with [MSMQ](/transports/msmq/) or [SQL](/transports/sql/) transports with [NHibernate](/persistence/nhibernate/) or [SQL](/persistence/sql/) persistence **and** if they are configured to share the transactional context (either through distributed transactions or connection sharing).
 
 NServiceBus provides a delayed-delivery implementation for transports that don't support it natively. All transports except MSMQ support delayed delivery natively.
 

servicecontrol/upgrades/3to4/index.md

@@ -28,9 +28,9 @@ ServiceControl Management Utility version 4 cannot be used to edit ServiceContro
 Upgrades that include the separate Audit embedded database will increase disk usage since databases are not automatically compacted. The new Audit embedded database will grow to the same peak storage usage as the original ServiceControl instance embedded audit message storage usage unless the original instance database is compacted after the data is removed via the audit retention process. This could result in as much as double the data usage.
 
 > [!NOTE]
-> After the upgrade is complete, the Audit information contained in the original ServiceControl instance will become read-only, but will continue to be deleted as it passes the time specified by the [retention policy](/servicecontrol/audit-instances/configuration.md#data-retention). However, since the internal database does not release storage space back to the OS, the database will continue to be the same size. If saga data was being audited in the original instance and no retention > policy is configured a custom check will fail, refer to the [troubleshooting guide](/servicecontrol/troubleshooting.md#saga-audit-data-retention-custom-check-failure) to resolve the issue.
+> After the upgrade is complete, the Audit information contained in the original ServiceControl instance will become read-only, but will continue to be deleted as it passes the time specified by the [retention policy](/servicecontrol/audit-instances/configuration.md#data-retention). However, since the internal database does not release storage space back to the OS, the database will continue to be the same size. If saga data was being audited in the original instance and no retention policy is configured a custom check will fail, refer to the [troubleshooting guide](/servicecontrol/troubleshooting.md#saga-audit-data-retention-custom-check-failure) to resolve the issue.
 >
-> After one retention period after the upgrade has been completed, the original ServiceControl instance's database will be mostly empty. At that point, the original database can be compacted to a very small size. See [Compacting RavenDB](/> servicecontrol/db-compaction.md) for instructions on compacting the database of the original ServiceControl instance once old audit messages have been cleaned up by the retention policy.
+> After one retention period after the upgrade has been completed, the original ServiceControl instance's database will be mostly empty. At that point, the original database can be compacted to a very small size. See [Compacting RavenDB](/servicecontrol/db-compaction.md) for instructions on compacting the database of the original ServiceControl instance once old audit messages have been cleaned up by the retention policy.
 
 ## ServiceControl Audit
 

transports/msmq/routing_content_msmqtransport_[1,).partial.md

@@ -8,7 +8,7 @@ The preferred way of configuring the physical routing is via the [instance mappi
 > When using instance mapping:
 >
 > * The settings will have no effect on **audit and error queues**.
-> * **publishing**: The publisher will publish messages only to endpoint instances that have subscribed to the events, ignoring the settings in the mapping file (the address of the subscriber that was provided in the subscription message will be > used).
+> * **publishing**: The publisher will publish messages only to endpoint instances that have subscribed to the events, ignoring the settings in the mapping file (the address of the subscriber that was provided in the subscription message will be used).
 > * **subscribing**: Subscription messages will be sent to all publisher instances listed in the instance mapping file.
 
 The instance mapping file is a simple XML file that has to be located either on a local hard drive or a network drive. When using MSMQ as the transport, NServiceBus will automatically look for an `instance-mapping.xml` file in `AppDomain.BaseDirectory`.