Интерфейс прикладной программы Winform «Тип аргумента не присваивается типу параметра»

Question

У меня есть приложение Winform, где я хотел бы реализовать какой-то интерфейс для клиента, поэтому части кода могут быть изменены клиентом позже, если они нужно. Я считаю, что мой подход ошибочен, потому что я получил ошибку в Visual Studio после перекомпиляции моего приложения Winform. Ошибка: «Тип аргумента MyClass не присваивается типу параметра MyClass», но я все еще могу его перекомпилировать. Я волнуюсь, это нарушило бы позже ...

Это, как я не реализовал ее до сих пор:

• В моей WinForm приложения Я создал абстрактный класс с виртуальным методом.
• Я «выпускаю» сборку dll с открытым исходным кодом для клиента, где реализован этот абстрактный класс, и метод вызывает базовый метод в абстрактном классе. Если клиент хочет изменить метод, он просто реализует его самостоятельно.
• Этот проект с открытым исходным кодом затем ссылается и реализуется в моем приложении winform.

Когда клиент хотел бы изменить метод, который они реализуют, перекомпилируйте dll и замените новую dll той, которую я распространил вместе с моей сборкой.

У моего приложения winform есть свое сильное имя, а проект с открытым исходным кодом имеет свое сильное имя.

Однако, когда я перекомпилирую свое приложение Winform после ссылки на проект с открытым исходным кодом, я получаю эту ошибку: «Тип аргумента MyClass не присваивается типу параметра MyClass». Я все еще могу перекомпилировать проект. Но я обеспокоен тем, что реализация имеет некоторые серьезные недостатки и позже будет ломаться. Особенно, так как я реализовал WyBuild, где я буду распространять обновления для приложения Winform.

Мне нужно предоставить клиенту возможность изменить некоторые методы в приложении без доступа ко всему исходному коду. Как это можно достичь, если моя реализация неверна, каково ваше предложение?

Спасибо.

Answer 1

Я бы сказал, что сам подход - это плохой способ сделать это. Для меня этот звук очень подвержен ошибкам, и вы утверждаете, что у вас плохое настроение. Если так, то действительно не делайте этого так.

Уверен, что существует несколько других решений, но, учитывая ваши описания, я мог бы сделать это следующим образом, чтобы сохранить ваше первоначальное намерение.

Обратите внимание на Microsoft Managed Extensibility Framework (MEF), который может помочь вам несколькими способами.

Проще говоря, это будет выглядеть так:

• Вы определите interface, что Custumer должен реализовать.
• Затем клиент создает сборку, которая реализует именно этот interface и помещает его в место, которое контролируется MEF
• MEF загружает сборку автоматически (нет необходимости изобретать колесо)

MEF дает вам много контроля над тем, как вы хотите, чтобы он работал.Например, как если бы он позволял загружать только или несколько сборок, которые реализуют этот интерфейс в одно и то же время, или должен искать только плагины только в начале приложения или контролировать местоположение плагина в течение всего срока его службы.

Кроме того, делая это таким образом, вы избавляетесь от настраиваемого решения, которое вы собираете здесь, и вместо этого используете зрелую структуру, которая обеспечивает стандартизированный способ сделать это. Просто посмотрите на некоторые учебные пособия в сети, на самом деле легко войти.