C# Warning CS0067: The event 'event' is never used

Suppose you're implementing an interface like the following, which contains some events you care about and some you don't:

 public interface I
{
    event EventHandler Important;
    event EventHandler Unimportant;
}

Forgetting about "unimportant" details, you'd probably start your implementation like this:

 public class C : I
{
    public event EventHandler Important;
  
    protected virtual void OnImportant(EventArgs e)
    {
        EventHandler handler = this.Important;
        if (handler != null)
        {
            handler(this, e);
        }
    }
}

Of course, if you compile at this point, you'll get an error like this:

 error CS0535: 'C' does not implement interface member 'I.Unimportant'

Obviously you need to define an implementation for Unimportant, even if you don't use it. Fortunately, it is very easy to implement an event:

 public event EventHandler Unimportant;

The problem with this implementation is that, since it is not ever used, and yet has a non-trivial compiler-generated implementation (which tracks the list of active handlers), the compiler issues the following warning:

 warning CS0067: The event 'C.Unimportant' is never used

The advice given by the compiler documentation isn't very helpful in this case; it just says you need to use the event. Other than creating a bogus reference to the event (or using '#pragma warning disable 67' to disable the warning), what does the compiler expect us to do? The right answer is to be explicit about what you expect from the event, which in this case, is nothing:

 public event EventHandler Unimportant
{
    add { }
    remove { }
}

This will cleanly suppress the warning, as well as the extra compiler-generated implementation of a normal event. And as another added benefit, it prompts one to think about whether this do-nothing implementation is really the best implementation. For instance, if the event isn't so much unimportant as it is unsupported, such that clients that do rely on the functionality are likely to fail without it, it might be better to explicitly indicate the lack of support and fail fast by throwing an exception:

 public event EventHandler Unsupported
{
    add { throw new NotSupportedException(); }
    remove { }
}

Of course, an interface that can be usefully implemented without some parts of its functionality is sometimes an indication that the interface is not optimally cohesive and should be split into separate interfaces.