CODEWITHSUNDEEP
c#.netwpfeventscompiler-warnings
jedmao
jedmao

Reputation: 10502

How do I get rid of "[some event] never used" compiler warnings in Visual Studio?

For example, I get this compiler warning,

The event 'Company.SomeControl.SearchClick' is never used.

But I know that it's used because commenting it out throws me like 20 new warnings of XAML pages that are trying to use this event!

What gives? Is there a trick to get rid of this warning?

Upvotes: 118

Views: 36251

Answers (7)

GrantA
GrantA

Reputation: 550

You can also do the following:

public event EventHandler MyEvent = static delegate {};

Upvotes: 8

vidstige
vidstige

Reputation: 13085

The second best way is imho to clearly state that the event is not supported by throwing an exception if someone tries to subscribe to it.

public event RoutedEventHandler SearchClick
{
    add { throw new NotSupportedException(); }
    remove { throw new NotSupportedException(); }
}

As a variant on this, you can also just leave the add and remove methods empty to silently ignore subscriptions on the event.

The best solution is to refactor the code, perhaps pull the declaration of the event to the implementor if possible.

As a last resort, you can also disable the warning like so

#pragma warning disable 67
public event RoutedEventHandler SearchClick;
#pragma warning restore 67

Upvotes: 22

lc.
lc.

Reputation: 116528

This appears to be warning 67 and can thus be suppressed with:

#pragma warning disable 67

Don't forget to restore it as soon as possible (after the event declaration) with:

#pragma warning restore 67

However, I'd check again and make sure you're raising the event somewhere, not just subscribing to it. The fact that the compiler spits out 20 warnings and not 20 errors when you comment out the event is also suspicious...

There's also an interesting article about this warning and specifically how it applies to interfaces; there's a good suggestion on how to deal with "unused" events. The important parts are:

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.

Upvotes: 190

Adam Mills
Adam Mills

Reputation: 8109

If you are forced to implement an event from an interface, that your implementation doesn't need you can do the following to avoid the warning.

public event EventHandler CanExecuteChanged { add{} remove{} }

Upvotes: 95

Simon
Simon

Reputation: 34880

Or you can add <NoWarn>67</NoWarn> to your project

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
  ...
  <NoWarn>67</NoWarn>
</PropertyGroup>

Upvotes: 0

Svend
Svend

Reputation: 8158

You can supress individual warnings.

\Program.cs(13,20): warning CS0219: The variable 'foo' is assigned but its value is never used

In this case, CS0219 is the warning regarding variables being assigned but not used. You can either use the /nowarn:0219 flag, or add the error number in the properties pane for the project (under "Build", remember to remove the leading CS). Keep in mind the supresses all warnings of this class.

Upvotes: 1

SLaks
SLaks

Reputation: 887987

The compiler is apparently not aware that it's being used in XAML code. Try suppressing the warning in your event definition.

Also, make sure you're actually raising the event somewhere.

Upvotes: 1

Related Questions