By default, transaction-aware bindings do not propagate transactions. The reason is that, like most everything else in WCF, this is an opt-in setting: the service host or administrator has to explicitly give its consent to accepting incoming transactions, potentially from across the organization or the business boundaries. To propagate a transaction, you must explicitly enable it in the binding on both the service host and client sides. All transaction-aware bindings offer the Boolean property TransactionFlow, such as:

public class NetTcpBinding : Binding,...
{
   public bool TransactionFlow
   {get;set;}
   //More members
}

TransactionFlow defaults to false. To enable propagation, simply set this property to true, either programmatically or in the host config file. For example, in the case of the TCP binding:

NetTcpBinding tcpBinding = new NetTcpBinding();
tcpBinding.TransactionFlow = true;

or when using a config file:

<bindings>
   <netTcpBinding>
      <binding name = "TransactionalTCP"
         transactionFlow = "true"
      />
   </netTcpBinding>
</bindings>

<netTcpBinding>
   <binding name = "TransactionalTCP" transactionFlow = "true">
      <reliableSession enabled = "true"/>
   </binding>
</netTcpBinding>

Using a transaction-aware binding and even enabling transaction flow does not mean that the service wants to use the client’s transaction in every operation, or that the client necessarily has a transaction to propagate in the first place. Such service-level decisions should be part of the contractual agreement between the client and the service. To that end, WCF provides the TransactionFlowAttribute method attribute, which controls if and when the client’s transaction flows into the service:

public enum TransactionFlowOption
{
   Allowed,
   NotAllowed,
   Mandatory
}

[AttributeUsage(AttributeTargets.Method)]
public sealed class TransactionFlowAttribute : Attribute,IOperationBehavior
{
   public TransactionFlowAttribute(TransactionFlowOption flowOption);
}

Note that the TransactionFlow attribute is a method-level attribute because WCF insists that the decision on transaction flow be made on a per-operation level, not at the service level:

[ServiceContract]
interface IMyContract
{
   [OperationContract]
   [TransactionFlow(TransactionFlowOption.Allowed)]
   void MyMethod();
}

This is deliberate, to enable the granularity of having some methods that use the client’s transaction and some that do not.

The value of the TransactionFlow attribute is included in the published metadata of the service, so when you import a contract definition, the imported definition will contain the configured value. WCF will also let you apply the TransactionFlow attribute directly on the service class implementing the operation:

[ServiceContract]
interface IMyContract
{
   [OperationContract]
   void MyMethod();
}
class MyService : IMyContract
{
   [TransactionFlow(TransactionFlowOption.Allowed)]
   public void MyMethod()
   {...}
}

However, such use is discouraged because it splits the definition of the logical service contract that will be published.

[ServiceContract]
interface IMyContract
{
   [OperationContract]
   void MyMethod();
}

[ServiceContract]
interface IMyContract
{
   [OperationContract]
   [TransactionFlow(TransactionFlowOption.NotAllowed)]
   void MyMethod();
}

Propagating the client’s transaction to the service requires, by its very nature, allowing the service to abort the client’s transaction if so desired. This implies that you cannot flow the client’s transaction to a service over a one-way operation, because that call does not have a reply message. WCF validates this at the service load time and will throw an exception when a one-way operation is configured with anything but TransactionFlowOption.NotAllowed:

//Invalid definition:
[ServiceContract]
interface IMyContract
{
   [OperationContract(IsOneWay = true)]
   [TransactionFlow(TransactionFlowOption.Allowed)]
   void MyMethod();
}