Я пытаюсь разработать приложение, которое использует плагины. У меня есть один проект для основного приложения, один для общих элементов, которые плагины могут / должны использовать, и один для тестового плагина. Основной проект и проект тестового плагина ссылаются на общие элементы. Если я оставлю для Copy Local значение true, то получу три копии общих элементов (будет хуже, когда у меня будет больше плагинов), и я думаю, что это испортит отражение. Когда основная программа пытается отразить пользовательский атрибут (определенный в общем), примененный к классу в тестовом плагине, используя
Object[] attributes = pluginType.GetCustomAttributes(typeof(PluginAttribute), true);
Я не нахожу атрибут, но когда делаю:
Object[] attributes = pluginType.GetCustomAttributes(true);
атрибут появляется в списке. Я предполагаю, что это потому, что основная программа и тестовый плагин получают PluginAttribute из разных сборок, поэтому они не рассматриваются как одно и то же.
Казалось бы, решение было бы отключить Copy Local. Однако, когда я это делаю, я получаю ошибку времени выполнения, что программа не может найти сборку, содержащую общие элементы. Как мне сообщить среде выполнения, где ее искать?
Любая помощь будет высоко ценится!
Edit:
Хорошо, вот еще несколько подробностей сценария.
У меня есть три проекта в решении. Один из них для dll, давайте назовем его Common, который я оставляю в каталоге, выбранном для него VS, поэтому dll заканчивается в ./Common/bin/Debug. DLL содержит определения интерфейса, который должны реализовывать все плагины: что-то вроде
namespace Common
{
[ContractClass(typeof(PluginContract))]
public interface IPlugin
{
String Foo();
}
}
Он также содержит определение класса атрибута, который может быть применен к плагинам, например:
public class PluginAttribute: Attribute
{
public String Bar {get; protected set;}
public PluginAttribute(String bar)
{
this.Bar = bar;
}
}
Следующим проектом является Host, который является исполняемым файлом. Опять же, это каталог по умолчанию, поэтому исполняемый файл находится в ./Host/bin/Debug. Он ищет сборки в ./Host/bin/Debug/Plugins и использует отражение для поиска в каждой сборке классов, реализующих IPlugin. Если это так, то я использую код, который я цитировал выше, чтобы увидеть, имеет ли он установлен PluginAttribute.
Последний проект - это тестовый плагин, который я установил для ./Host/bin/Debug/Plugins.
namespace TestPlugin
{
[PluginAttribute("Test Class")]
public class TestClass: IPlugin
{
public string Foo()
{
return "Foo";
}
}
}
Хост находит TestClass в сборке TestPlugin очень хорошо, но у меня проблемы с доступом к атрибуту Plugin. Моя догадка состоит в том, что это потому, что у меня есть три копии Common.dll, и что есть проблема с Хостом, использующим копию в ./Host/bin/Debug, но TestClass предположительно построен с копией в ./Host/bin/Debug/Plugins , физически другой dll (делает ли это другой сборкой, или это просто еще одна копия того же самого dll?) Итак, чтобы развить это предположение, я попытался установить для параметра «Локальное копирование» значение false, поэтому я получил только одну копию Common.dll в ./Common/bin/Debug. Это прекрасно работает, но выдает ошибку времени выполнения, что не может загрузить общую сборку.