Як я можу позбутися попереджень компілятора [[якась подія] ніколи не використовувалась] у Visual Studio?

Question 1

Наприклад, я отримую це попередження компілятора,

Подія "Company.SomeControl.SearchClick" ніколи не використовується.

Але я знаю, що він використовується, тому що його коментування видає мені як 20 нових попереджень сторінок XAML, які намагаються використати цю подію!

Що дає? Чи є хитрість, щоб позбутися цього попередження?

Question 2

Здається, це попередження 67, і тому його можна придушити за допомогою:

#pragma warning disable 67

Не забудьте відновити його якомога швидше (після оголошення події) за допомогою:

#pragma warning restore 67

Однак я б перевірив ще раз і переконався, що ви десь піднімаєте подію, а не просто підписуєтесь на неї. Той факт, що компілятор видає 20 попереджень, а не 20 помилок, коли ви коментуєте подію, також є підозрілим ...

Також є цікава стаття про це попередження, а також про те, як воно застосовується до інтерфейсів; є гарна порада щодо того, як поводитися з "невикористаними" подіями. Важливими частинами є:

Правильна відповідь полягає в тому, щоб чітко визначити, чого ви очікуєте від події, а в цьому випадку це ніщо:
public event EventHandler Unimportant
{
    add { }
    remove { }
}
Це дозволить чітко придушити попередження, а також додаткову компіляторну реалізацію звичайної події. І як ще одна додаткова перевага, це спонукає задуматися про те, чи справді ця реалізація нічого не є найкращою реалізацією. Наприклад, якщо подія не є настільки важливою, скільки непідтримуваною, так що клієнти, які покладаються на функціонал, швидше за все, зазнають невдачі без неї, може бути краще чітко вказати на відсутність підтримки і швидко вийти з ладу, кинувши виняток:
public event EventHandler Unsupported
{
    add { throw new NotSupportedException(); }
    remove { }
}
Звичайно, інтерфейс, який може бути корисно реалізований без деяких частин його функціональних можливостей, іноді є свідченням того, що інтерфейс не є оптимально цілісним і повинен бути розділений на окремі інтерфейси.

Question 3

Якщо ви змушені реалізовувати подію з інтерфейсу, а ваша реалізація не потрібна, ви можете зробити наступне, щоб уникнути попередження.

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

Question 4

Другий найкращий спосіб - це імхо чітко заявити, що подія не підтримується, викидаючи виняток, якщо хтось намагається на нього підписатися.

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

Як варіант цього, ви також можете просто залишити методи addі removeпустими, щоб мовчки ігнорувати підписки на подію.

Найкращим рішенням є рефакторинг коду, можливо, перетягнення оголошення про подію до реалізатора, якщо це можливо.

В крайньому випадку, ви також можете вимкнути попередження так

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

Question 5

Ви також можете зробити наступне:

public event EventHandler MyEvent = delegate {}

Question 6

Компілятор, мабуть, не знає, що він використовується в коді XAML. Спробуйте придушити попередження у своєму визначенні події.

Також переконайтеся, що ви насправді десь піднімаєте подію.

Question 7

Ви можете придушити окремі попередження.

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

У цьому випадку CS0219 є попередженням щодо змінних, які призначаються, але не використовуються. Ви можете використовувати прапор / nowarn: 0219 або додати номер помилки на панелі властивостей проекту (у розділі "Збірка" не забудьте видалити провідну CS). Майте на увазі пригнічує всі попередження цього класу.

Question 8

Або ви можете додати <NoWarn>67</NoWarn>до свого проекту

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