Introduction

The C# compiler warning for an event that is "never used" is usually correct: the event is declared, but nothing in the declaring type ever raises it. The right fix depends on intent. Sometimes the event should be removed, sometimes it should actually be raised, and sometimes the clean answer is to suppress the warning explicitly.

Why the warning appears

In C#, only the declaring type can invoke an event. External subscribers can attach handlers, but they cannot raise the event. Because of that, the compiler treats an event as unused if your type never invokes it or otherwise references it internally.

This often happens with placeholder APIs such as:

1public class Worker
2{
3    public event EventHandler? Completed;
4}

If Completed is never raised, the compiler warns because the event is dead code from the type's own point of view.

Best fix: remove or use the event

If the event is no longer part of a real API, delete it. That is the cleanest solution.

If the event is supposed to exist, then implement the behavior and raise it:

1using System;
2
3public class Worker
4{
5    public event EventHandler? Completed;
6
7    public void Run()
8    {
9        Console.WriteLine("working...");
10        Completed?.Invoke(this, EventArgs.Empty);
11    }
12}

This removes the warning because the event is now genuinely used.

When suppression is the correct answer

Sometimes the event exists only because:

• a framework or interface requires it
• a base-class contract expects it
• the event is reserved for future compatibility

In those cases, raising a fake event just to satisfy the compiler is worse than the warning. Use a targeted suppression instead:

1public sealed class NullWorker
2{
3#pragma warning disable CS0067
4    public event EventHandler? Completed;
5#pragma warning restore CS0067
6}

This keeps the intent obvious. It says, in effect, "yes, this event is intentionally unused."

A better option for interface-only placeholders

If the event is part of an interface but your implementation will never publish it meaningfully, a custom event can make that explicit:

1using System;
2
3public interface IWorker
4{
5    event EventHandler? Completed;
6}
7
8public sealed class NoOpWorker : IWorker
9{
10    public event EventHandler? Completed
11    {
12        add { }
13        remove { }
14    }
15}

This is useful when the event is required for shape compatibility, but the implementation intentionally has no event source behind it.

Use this sparingly. Empty event accessors are clear only when the type truly has nothing to notify.

Avoid broad warning suppression

It is tempting to disable the warning project-wide in Visual Studio or in the project file. That usually throws away useful signal. Compiler warnings about unused members often catch real cleanup opportunities.

Prefer one of these:

• remove the event
• implement the event
• suppress CS0067 at the smallest possible scope

That keeps the rest of the project honest.

Common Pitfalls

• Keeping dead events around because they might be useful later. That tends to create noisy APIs.
• Invoking an event artificially only to silence the warning, even though the event has no real meaning.
• Disabling the warning globally instead of suppressing it where the unused event is intentional.
• Forgetting that subscribers using the event from outside the class do not count as internal usage for the compiler.
• Using empty custom event accessors when the type really should expose a functioning event.

Summary

• The warning appears because the declaring type never uses or raises the event.
• The best fix is to remove the event or implement it properly.
• If the event is intentionally unused, suppress CS0067 locally.
• Custom empty event accessors can be appropriate for interface or compatibility scenarios.
• Avoid project-wide suppression unless you genuinely want to lose that warning everywhere.