Архитектура плагина C# с сильными именами: недоразумение

Question

У меня есть исполняемый файл сервера, который разговаривает с Active Directory, чтобы получить информацию о пользователе. Помимо AD, этот exe позволяет клиентам писать свои собственные плагины для общения с пользовательскими каталогами пользователей.

Этот исполняемый файл имеет сильное имя.

Является ли следующее верное утверждение:

Для того, чтобы сильно по имени сборки, чтобы загрузить другую сборку, то загружен узел должен быть подписан с тем же ключом.

Следующий код возвращает значение null, если сборка не была сильно подписана, без ошибки, указывающей, что сборка была неправильно подписана. Обратите внимание: если я подписываю сборку, я получаю экземпляр IService. Это заставляет меня думать, что загруженные сборки должны быть строго подписаны.

Assembly assembly = Assembly.LoadFrom(path); 

foreach (Type t in assembly.GetTypes()) 
{ 
    if (t.GetInterface(typeof(IService).FullName) != null) 
    { 
     return (Activator.CreateInstance(t) as IService); 
    } 
} 

Так, значит ли это, если у вас есть сильно подписанная сборка и поддержка сборки плагин, они также должны быть подписаны - плагин авторы должны подписать их с тем же ключом? Это звучит не так.

Наконец, скажем, у меня есть сборка, которая реализует интерфейс IService, но также ссылается на сборку, которая ссылается на еще одну сборку, каждая из которых подписана с другим ключом. Что происходит, когда я пытаюсь загрузить? Должны ли все они быть подписаны одним и тем же ключом?

Answer 1

Следующее утверждение является правильным:

Для того, чтобы сильно по имени узла , чтобы загрузить другую сборку, загруженную узел также должен быть подписан с тот же ключ .

От MSDN:

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

---

Edit: D'ой! Хотя мой ответ верен, как указывает Пади, это не имеет значения!

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

Я воссоздал свой код (или, по крайней мере, близкое приближение), со следующими узлами:

• Interface.dll (подписал, содержит IService)

• Loader.exe (подписал, а консольное приложение, которое принимает path, использует ваш код для загрузки и возврата первого IService, который он находит в сборке, указанной этим path, затем называет IService метод)

• Plugin.dll (не авторизованы, содержит

Следующая я добавил Plugin.dll ссылку на Loaded.exe и пытался получить доступ к его IService реализации, которые не удалось IService реализации) как и ожидалось, со следующим сообщением: «Сборка сборки не удалась - ссылка на сборку« Плагин »не имеет сильного имени».

Наконец, я запустил консольное приложение, передал ему имя слабо названного Plugin.dll, и он работал отлично.

Кажется, что-то еще происходит. Scott Hanselman has blogged about the vagaries of dynamic assembly loading on several occasions, и он указывает на Suzanne Cook's blog за авторитетные подробности по этой теме.

Answer 2

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

Answer 3

Заявление неверно - ссылочные сборки должны быть подписаны, но не обязательно с одним и тем же ключом.

Когда вы ссылаетесь на сильную именованную сборку, вы ожидаете получить определенные преимущества, такие как управление версиями и защита имен. Если сборка с сильным именем затем ссылается на сборку с простым именем, которая не имеет этих преимуществ, вы теряете преимущества, получаемые от использования сборки с сильным именем, и возвращаетесь к конфликтам DLL. Поэтому узлы с сильным именем могут ссылаться только на другие узлы с сильными именами.

(Взято из MSDN Library)