Microsoft.CodeAnalysis.CodeActions Namespace

Classes

ApplyChangesOperation	A CodeActionOperation for applying solution changes to a workspace. GetOperationsAsync(CancellationToken) may return at most one ApplyChangesOperation. Hosts may provide custom handling for ApplyChangesOperations, but if a CodeAction requires custom host behavior not supported by a single ApplyChangesOperation, then instead:
CodeAction	An action produced by a CodeFixProvider or a CodeRefactoringProvider.
CodeActionOperation	Represents a single operation of a multi-operation code action.
CodeActionWithOptions	A CodeAction that can vary with user specified options. Override one of ComputeOperationsAsync(Object, CancellationToken) or ComputeOperationsAsync(Object, IProgress<CodeAnalysisProgress>, CancellationToken) to actually compute the operations for this action.
ConflictAnnotation	Apply this annotation to a SyntaxNode to indicate a conflict may exist that requires user understanding and acknowledgment before taking action.
OpenDocumentOperation	A code action operation for requesting a document be opened in the host environment.
PreviewOperation	Represents a preview operation for generating a custom user preview for the operation.
RenameAnnotation	Apply this annotation to an appropriate SyntaxNode to request that it should be renamed by the user after the action.
WarningAnnotation	Apply this annotation to a SyntaxNode to indicate that a warning message should be presented to the user.

Enums

CodeActionPriority

Priority of a particular code action produced by either a CodeRefactoringProvider or a CodeFixProvider. Code actions use priorities to group themselves, with lower priority actions showing up after higher priority ones. Providers should put less relevant code actions into lower priority buckets to have them appear later in the UI, allowing the user to get to important code actions more quickly.

CodeActionRequestPriority

Priority class that a particular CodeRefactoringProvider or CodeFixProvider should run at. Providers are run in priority order, allowing the results of higher priority providers to be computed and shown to the user without having to wait on, or share computing resources with, lower priority providers. Providers should choose lower priority classes if they are either: Very slow. Slow providers will impede computing results for other providers in the same priority class. So running in a lower one means that fast providers can still get their results to users quickly. Less relevant. Providers that commonly show available options, but those options are less likely to be taken, should run in lower priority groups. This helps ensure their items are still there when the user wants them, but aren't as prominently shown.