Как я должен дополнительно ссылаться на проект библиотеки классов в другом проекте .NET?

Настройте свои проекты так, чтобы исполняемый файл был скомпилирован в 1 место, а ваши «плагины» скомпилированы в одно и то же место. Вы можете использовать Junctions, чтобы сделать «bin» путем к вашему конечному местоположению.

Также в вашем проекте плагина установите исполняемый файл в качестве хоста отладки.

Если вы еще этого не сделали, убедитесь, что ваш интерфейс не перекомпилируется при каждой компиляции вашего исполняемого файла (если он имеет строгое имя), потому что это заставит вас перекомпилировать каждый из ваших плагинов каждый раз, когда вы перекомпилируете свой исполняемый файл. хост exe.

Для модели плагина я бы посмотрел на методы Activator.CreateInstance и Activator.CreateInstanceFrom или даже взглянул бы на Assembly.LoadFrom. Эти методы позволяют загружать типы из сборок в каталоги, отличные от «традиционных» выходных каталогов (bin, debug, release).

Принуждение Type.GetType к поиску ваших сборок «плагинов» действительно зависит от того, как вы изменяете политику для загрузчика для поиска сборок. Например, вы можете установить свойство AppDomain.PrivateBinPath, чтобы изменить подкаталоги, в которых загрузчик будет искать ссылочные сборки.

По поводу первого пункта "Добавление ссылок на проекты плагинов". Что ж, это может привести к сложной ситуации, препятствующей расширению в будущем. Что, если я хочу создать новый подключаемый модуль? Ой, теперь у вас нет ссылки на него, и я думаю, что тогда мой плагин не будет работать? Вот почему должен быть другой подход. Один из них мы бы «прощупали» на наличие сборок плагинов.

Примечание
В модели подключаемых модулей все подключаемые модули должны работать с общим интерфейсом (или абстрактным классом), и это действительно эта реализация, которую вы ищете во всех новых подключаемых модулях, которые вы нагрузка. Например:

private void LoadAllPlugins(string path)
{
    foreach(string file in Directory.GetFiles(path, "*.dll"))
    {
        Assembly a = Assembly.LoadFrom(file);
        foreach(Type t in a.GetTypes())
        {
            if (t.GetInterface("IMyPluginInterface", true))
            {
               // we now have a potential plugin type that implements required functionality
            }
        }
    }
}

Наконец, .NET 3.5 поддерживает модель подключаемых модулей (System.AddIn), а также ознакомьтесь с версией Managed Extensibility Framework от Microsoft, которая позволяет разработчикам создавать простые компонуемые подключаемые модули (http://www.codeplex.com/MEF)

Просто включите проекты плагинов в свое решение, но только с зависимостью от плагинов к проектам «приложений». Обеспечьте это, сохранив дубликат решения, но только с проектом (проектами) приложения и обеспечив чистоту сборки. Вы также можете рассмотреть этап пост-сборки, который пытается собрать каждый проект плагина отдельно без других.

Еще одна проверка — хотите ли вы обеспечить обратную совместимость или, по крайней мере, знать, когда произошел очевидный сбой. Это проще всего, если у вас есть тестовый проект, который ссылается на подключаемые модули по ссылке dll, а не по ссылке на проект (небольшое раздражение в тестовом проекте). Затем, изменив путь к ссылкам в настройках проекта, вы можете указать на старые версии плагинов. Выполнить это должным образом как часть тестов по сценарию также достаточно просто.

Я бы поддержал предложение использовать систему MEF, если ваши плагины эффективно известны во время компиляции, но не конкретная версия dll, которую вы планируете загрузить.

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

У меня есть две статьи, объясняющие это: Система плагинов для C#. Часть I. Концепции и Система плагинов с C#. Часть II. El código explicado, но у меня пока нет времени их переводить (поэтому они на испанском). Тем не менее код прокомментирован на английском языке (если я правильно помню).

Я попытаюсь объяснить свой подход здесь.

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

Тогда у вас есть два вида аспектов для плагинов.

Сначала подключаемый модуль может предложить услугу другим классам, реализовав общедоступный (известный) интерфейс и пометив себя как услугу с помощью «ServiceAttribute». Затем система плагинов зарегистрирует сервис и сделает его общедоступным для всех, кто заинтересован в его использовании. Например:

ICrypt crypto = Plugins.Service["Crypt"] as ICrypt;
if (crypto != null)
  crypto.Crypt(data, key, etc)

С другой стороны, у вас есть крючки. Хуки — это события плагина. У вас есть два атрибута HookAttribute и HookableAttribute.

Когда вы объявляете метод как Hookable, вы говорите, что ожидаете, что он будет перехвачен другими плагинами. Например

[Hookable]
public event TextChanged OnTextChanged;
//.....
if (OnTextChanged != null)
  OnTextChanged(ref myText);

и в другом плагине

[Hooks("OnTextChanged")]
public bool MyTextChanged(ref myText)
{
  myText = "Hello from the plugin";
  return true;
}

Подпись ловушки (делегат) может быть неизвестна до тех пор, пока подпись совпадает. Опять же, система плагинов обрабатывает совпадения и объединяет их.

Он также включает в себя некоторые атрибуты для выражения зависимостей между плагинами и автоматическим обнаружением и загрузкой и тому подобными вещами. Сам проект находится под лицензией LGPL, так что вы можете найти в нем какие-то идеи или даже лучше... внести свой вклад :P

Кстати, я использую подпапку Plugins, куда помещаю плагины. У меня нет проблем с их отладкой из VS, если проект плагина является частью решения, над которым я работаю. Мне не нужно ссылаться на них или что-то еще. Если плагин является частью решения, я могу его отладить.