Remove superfluous, irrelevant, extraneous, and immaterial marker ref…

…erences

nservicebus/concept-overview.md

@@ -17,7 +17,7 @@ A Message is the unit of communication for NServiceBus. Messages are send and re
  * [Command](/nservicebus/messaging/messages-events-commands.md): Used to request that an action should be taken.
  * [Event](/nservicebus/messaging/messages-events-commands.md): Used to communicate that some action has taken place.
 
-Message types can be set either using marker interfaces `ICommand` and `IEvent` or via [conventions](/nservicebus/messaging/unobtrusive-mode.md) (so called *unobtrusive mode*).
+Message types can be set either using interfaces `ICommand` and `IEvent` or via [conventions](/nservicebus/messaging/unobtrusive-mode.md) (so called *unobtrusive mode*).
 
 
 ### Body

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

@@ -14,7 +14,7 @@ include: host-deprecated-warning
 
 ## Custom profile
 
-In certain scenarios it might be useful to define additional profiles. For example, some organizations have a few testing or staging environments that might require different configurations. To define a custom Profile create a class that implements the `NServiceBus.IProfile` marker interface:
+In certain scenarios it might be useful to define additional profiles. For example, some organizations have a few testing or staging environments that might require different configurations. To define a custom Profile create a class that implements the `NServiceBus.IProfile` interface:
 
 snippet: defining_profile
 

nservicebus/messaging/conventions.md

@@ -11,7 +11,7 @@ related:
  - nservicebus/messaging/unobtrusive-mode
 ---
 
-A *convention* is a way of defining what a certain type is instead of using a marker interface or an attribute. Using conventions along with avoiding references to NServiceBus assemblies is referred to as *[unobtrusive mode](unobtrusive-mode.md)*. This is ideal for use in cross-platform environments.
+A *convention* is a way of defining what a certain type is instead of using an interface or an attribute. Using conventions along with avoiding references to NServiceBus assemblies is referred to as *[unobtrusive mode](unobtrusive-mode.md)*. This is ideal for use in cross-platform environments.
 
 Currently conventions exist to identify:
 

nservicebus/messaging/headers.md

@@ -190,7 +190,7 @@ snippet: HeaderWriterReturnReturning
 
 ### NServiceBus.ClearTimeouts
 
-A marker header to indicate that the contained control message is requesting that timeouts be cleared for a given saga.
+A header to indicate that the contained control message is requesting that timeouts be cleared for a given saga.
 
 
 ### NServiceBus.Timeout.Expire
@@ -205,7 +205,7 @@ The queue name a timeout should be routed back to when it fires.
 
 ### NServiceBus.IsDeferredMessage
 
-A marker header to indicate that this message resulted from a Defer.
+A header to indicate that this message resulted from a Defer.
 
 
 ## Saga-related headers

nservicebus/messaging/messages-events-commands.md

@@ -55,12 +55,12 @@ partial: errors
 
 ## Defining Messages
 
-Messages can be defined via *marker interfaces* or via *conventions*.
+Messages can be defined via *interfaces* or via *conventions*.
 
 
-### Marker interfaces
+### Interfaces
 
-The simplest way to define a message is to use marker interfaces.
+The simplest way to define a message is to use interfaces.
 
  * `NServiceBus.IMessage` for defining a Message.
  * `NServiceBus.ICommand` for defining a Command.

nservicebus/messaging/publish-subscribe/publish-handle-event.md

@@ -14,12 +14,12 @@ related:
 
 ## Defining events
 
-The messages need to be declared as an event before they can be published. That can be done with marker interfaces or using message conventions.
+The messages need to be declared as an event before they can be published. That can be done with interfaces or using message conventions.
 
 
-### Via a Marker interface
+### Via an interface
 
-Add `IEvent` marker interface to the message definition:
+Add the `IEvent` interface to the message definition:
 
 snippet: EventWithInterface
 

nservicebus/upgrades/4to5.md

@@ -58,7 +58,7 @@ Reflection calls that makes assumptions on the assembly name of `NServiceBus.dll
 Any binding redirects pointing to `NServiceBus.dll` should be removed.
 
 
-### Use of marker interfaces and attributes from  NServiceBus.Interfaces.dll
+### Use of interfaces and attributes from  NServiceBus.Interfaces.dll
 
 The following have been moved into `NServiceBus.Core.dll` (part of the `NServiceBus` NuGet)
 

samples/pubsub/sample.md

@@ -23,7 +23,7 @@ Before running the sample, look over the solution structure, the projects, and t
 
 ## Defining messages
 
-The `Shared` project contains the definition of the messages that are sent between the processes. Open "OrderReceived.cs" to see the message that will be published by this sample. Note that this event implements a marker interface called `IEvent` to denote that this message is an event. To define messages without adding a dependency to NServiceBus, use [Unobtrusive Mode Messages](/nservicebus/messaging/unobtrusive-mode.md). 
+The `Shared` project contains the definition of the messages that are sent between the processes. Open "OrderReceived.cs" to see the message that will be published by this sample. Note that this event implements an interface called `IEvent` to denote that this message is an event. To define messages without adding a dependency to NServiceBus, use [Unobtrusive Mode Messages](/nservicebus/messaging/unobtrusive-mode.md). 
 
 
 ## Creating and publishing messages

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

@@ -22,6 +22,6 @@ or for an assembly containing multiple event types:
 
 snippet: publisher_names_mapping_by_assembly
 
-In the latter case, the transport analyzes all types in the assembly to identify which are events, using marker interface `IEvent` or the configured `DefiningEventsAs()` [message convention](/nservicebus/messaging/conventions.md). Then for each event type, the transport registers a mapping between the type and the publisher name.
+In the latter case, the transport analyzes all types in the assembly to identify which are events, using the `IEvent` interface or the configured `DefiningEventsAs()` [message convention](/nservicebus/messaging/conventions.md). Then for each event type, the transport registers a mapping between the type and the publisher name.
 
 In the snippets the **publisherName** is the name of the endpoint that will publish messages.

transports/rabbitmq/routing-topology.md

@@ -70,7 +70,7 @@ The default conventions for exchange names and routing keys can be overridden by
 
 snippet: rabbitmq-config-usedirectroutingtopologywithcustomconventions
 
-WARNING: In some cases, the direct routing topology may not deliver message types with "non-system" interfaces in their inheritance hierarchy. A "non-system" interface is any interface which is not contained in a .NET Framework assembly (any assembly signed with the same public key as mscorlib), and is not one of the [marker interfaces](/nservicebus/messaging/messages-events-commands.md#defining-messages-marker-interfaces). When using the direct routing topology, message types must not inherit from "non-system" interfaces. To guarantee delivery of message types which inherit from non-system interfaces, the conventional routing topology must be used.
+WARNING: In some cases, the direct routing topology may not deliver message types with "non-system" interfaces in their inheritance hierarchy. A "non-system" interface is any interface which is not contained in a .NET Framework assembly (any assembly signed with the same public key as mscorlib), and is not one of the [interfaces](/nservicebus/messaging/messages-events-commands.md#defining-messages-interfaces). When using the direct routing topology, message types must not inherit from "non-system" interfaces. To guarantee delivery of message types which inherit from non-system interfaces, the conventional routing topology must be used.
 
 
 partial: exchange-queue-durability

tutorials/nservicebus-step-by-step/2-sending-a-command/tutorial.md

@@ -22,7 +22,7 @@ A [**message**](/nservicebus/messaging/messages-events-commands.md) is a collect
 
 In this lesson, we'll focus on [commands](/nservicebus/messaging/messages-events-commands.md#command). In [Lesson 4: Publishing events](../4-publishing-events/) we'll expand to look at events as well.
 
-To define a command, create a class and mark it with the `ICommand` marker interface.
+To define a command, create a class and mark it with the `ICommand` interface.
 
 snippet: Command
 

tutorials/nservicebus-step-by-step/4-publishing-events/tutorial.md

@@ -36,7 +36,7 @@ Let's take a look at all of these differences side-by-side:
 
 |   | Commands | Events |
 |---|:--------:|:------:|
-| Marker Interface | `ICommand` | `IEvent` |
+| Interface | `ICommand` | `IEvent` |
 | Logical Senders | Many | 1 |
 | Logical Receivers | 1 | Many (or none) |
 | Purpose | "Please do something" | "Something has happened" |
@@ -66,7 +66,7 @@ This means that when the code for the credit card processing changes, we don't e
 
 ## Defining events
 
-Creating an event message is just similar to creating a command. We just create a class and mark it with the `IEvent` (rather than `ICommand`) marker interface.
+Creating an event message is just similar to creating a command. We just create a class and mark it with the `IEvent` (rather than `ICommand`) interface.
 
 snippet: Event