CA1068: CancellationToken parameters must come last

Value
Rule ID CA1068
Category Microsoft.Design
Fix is breaking or non-breaking Breaking

Cause

A method has a CancellationToken parameter that is not the last parameter.

By default, this rule analyzes the entire codebase, but this is configurable.

Rule description

Methods that perform long running operations or asynchronous operations and are cancelable normally take a cancellation token parameter. Each cancellation token has a CancellationTokenSource that creates the token and uses it for cancelable computations. It is common practice to have a long chain of method calls that pass around the cancellation token from the callers to the callees. Hence, a large number of methods that take part in a cancelable computation end up having a cancellation token parameter. However, the cancellation token itself is not usually relevant to the core functionality of a majority of these methods. It's considered a good API design practice to have such parameters be the last parameter in the list.

Special cases

Rule CA1068 does not fire in the following special cases:

  • Method has one or more optional parameters (Optional in Visual Basic) following a non-optional cancellation token parameter. The compiler requires that all optional parameters are defined after all the non-optional parameters.
  • Method has one or more ref or out parameters (ByRef in Visual Basic) following a cancellation token parameter. It is common practice to have ref or out parameters be at the end of the list, because they usually indicate output values for the method.

How to fix violations

Change the method signature to move the cancellation token parameter to the end of the list. For example, the following two code snippets show a violation of the rule and how to fix it:

// Violates CA1068
public void LongRunningOperation(CancellationToken token, string usefulParameter)
{
    ...
}
// Does not violate CA1068
public void LongRunningOperation(string usefulParameter, CancellationToken token)
{
    ...
}

When to suppress warnings

If the method is an externally visible public API that is already part of a shipped library, then it is safe to suppress a warning from this rule to avoid a breaking change for the library consumers.

Configure code to analyze

Use the following options to configure which parts of your codebase to run this rule on.

You can configure these options for just this rule, for all rules, or for all rules in this category (Design). For more information, see Code quality rule configuration options.

Include specific API surfaces

You can configure which parts of your codebase to run this rule on, based on their accessibility. For example, to specify that the rule should run only against the non-public API surface, add the following key-value pair to an .editorconfig file in your project:

dotnet_code_quality.CAXXXX.api_surface = private, internal

Exclude specific symbols

You can exclude specific symbols, such as types and methods, from analysis. For example, to specify that the rule should not run on any code within types named MyType, add the following key-value pair to an .editorconfig file in your project:

dotnet_code_quality.CAXXXX.excluded_symbol_names = MyType

Allowed symbol name formats in the option value (separated by |):

  • Symbol name only (includes all symbols with the name, regardless of the containing type or namespace).
  • Fully qualified names in the symbol's documentation ID format. Each symbol name requires a symbol-kind prefix, such as M: for methods, T: for types, and N: for namespaces.
  • .ctor for constructors and .cctor for static constructors.

Examples:

Option Value Summary
dotnet_code_quality.CAXXXX.excluded_symbol_names = MyType Matches all symbols named MyType.
dotnet_code_quality.CAXXXX.excluded_symbol_names = MyType1|MyType2 Matches all symbols named either MyType1 or MyType2.
dotnet_code_quality.CAXXXX.excluded_symbol_names = M:NS.MyType.MyMethod(ParamType) Matches specific method MyMethod with the specified fully qualified signature.
dotnet_code_quality.CAXXXX.excluded_symbol_names = M:NS1.MyType1.MyMethod1(ParamType)|M:NS2.MyType2.MyMethod2(ParamType) Matches specific methods MyMethod1 and MyMethod2 with the respective fully qualified signatures.

Exclude specific types and their derived types

You can exclude specific types and their derived types from analysis. For example, to specify that the rule should not run on any methods within types named MyType and their derived types, add the following key-value pair to an .editorconfig file in your project:

dotnet_code_quality.CAXXXX.excluded_type_names_with_derived_types = MyType

Allowed symbol name formats in the option value (separated by |):

  • Type name only (includes all types with the name, regardless of the containing type or namespace).
  • Fully qualified names in the symbol's documentation ID format, with an optional T: prefix.

Examples:

Option Value Summary
dotnet_code_quality.CAXXXX.excluded_type_names_with_derived_types = MyType Matches all types named MyType and all of their derived types.
dotnet_code_quality.CAXXXX.excluded_type_names_with_derived_types = MyType1|MyType2 Matches all types named either MyType1 or MyType2 and all of their derived types.
dotnet_code_quality.CAXXXX.excluded_type_names_with_derived_types = M:NS.MyType Matches specific type MyType with given fully qualified name and all of its derived types.
dotnet_code_quality.CAXXXX.excluded_type_names_with_derived_types = M:NS1.MyType1|M:NS2.MyType2 Matches specific types MyType1 and MyType2 with the respective fully qualified names, and all of their derived types.

See also