Есть ли известная проблема с VS2017 и его способностью правильно заглушить универсальный метод, имеющий два ограничения типа? - PullRequest
0 голосов
/ 29 марта 2019

Я обнаружил, что при применении контекстного меню «Быстрые действия и рефакторинги ...» в Visual Studio 2017 для реализации интерфейса нового класса, этот интерфейс содержит универсальный метод, имеющий два ограничения типа - например: Класс IModel - не дает ожидаемого результата. Смотрите код, который я использовал далее в этом посте.

Я попытался добавить базовое свойство в интерфейс IModel с тем же результатом. Я удалил ограничение "class" и оставил ограничение IModel, и это работает как ожидалось. Я попробовал обратное - убрать ограничение IModel, оставив ограничение «class», которое, конечно, работает как положено. Это только странное поведение проявляется только у меня обоих.

Я хотел посмотреть, был ли он изолирован от VS2017, поэтому я установил CTP VS2019, создал код в моем примере ниже и получил тот же результат.

Но когда я тестировал один и тот же сценарий в VS2010 и VS2012, я не получил неожиданного поведения, и у моего класса был общий универсальный метод с двумя ограничениями.

Я знаю, что есть и другие опции, такие как абстрактный базовый класс, который реализует IModel, тогда как универсальный метод имеет ограничение одного типа для этого базового класса. И я, конечно, могу просто помочь VS2017, исправив результат Quick Actions и Refactorings, и это работает хорошо, но мне было любопытно, сталкивался ли кто-нибудь еще с этим. Возможно, я пропустил новую опцию конфигурации в IDE?

Следующий код - это то, что я использовал для сравнения во всех четырех версиях Visual Studio (для простоты я создал этот код в новом Консольном приложении (.Net Framework), чтобы устранить любые шумы):

public interface IModel { }
public interface IReader
{
   IList<T> GetList<T>() where T: class, IModel;
}
public class MyReader : IReader
{
  //Using Ctrl+. to implement IReader in VS2017,VS2019 produces this:
  IList<T> IReader.GetList<T>() { ... }

  //Using Ctrl+. under VS2010,VS2012 produces expected:
  public IList<T> GetList<T>() where T: class, IModel { ... }
}

Я ожидал, что VS2017 реализует этот интерфейс правильно, как показано в предыдущих версиях, но кажется, что VS2017 и даже CTP VS2019 запутываются из-за наличия обоих «классов» вместе с другим ограничением, которое является интерфейсом, как показано в приведенном выше коде .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...