Создайте свой собственный кэш сборки .NET

В приложении .net, которое я пишу, мне нужно локально кэшировать сборки из разных мест, чтобы мое приложение могло использовать их, даже если исходные места недоступны. Я не могу использовать GAC (в первую очередь потому, что мне нужна переносимость, а также потому, что сборки могут быть не подписаны).

Кто-нибудь знает какой-либо код .net, который уже поддерживает эту функцию? Мне нужно, чтобы кеш мог сообщить мне, находится ли конкретная сборка в кеше, а также обрабатывать разные версии сборок. Вполне вероятно, что мне придется прибегнуть к написанию собственного кэша сборки, но я подумал, что задам этот вопрос, потому что мне не очень хочется «изобретать велосипед», если это уже было сделано.


person Zach Johnson    schedule 04.04.2009    source источник


Ответы (2)


В Mono проекте пришлось (повторно) внедрить GAC, и он работает в Windows. Я бы начал оттуда.

person Shay Erlichmen    schedule 04.04.2009

В итоге мне пришлось написать свой собственный кеш сборки...

Вот основы того, как это работает, чтобы помочь другим, если им нужно реализовать собственный кеш сборки:

  • Кэш — это папка с соответствующим классом-оболочкой в ​​приложении.
  • Метод установки сборки в кэш возвращает строковый маркер (имя, под которым установлена ​​сборка), который вызывающая сторона может сохранить и использовать для последующего извлечения сборки.
  • Метод получения сборки принимает токен и возвращает объект, который инкапсулирует информацию о кэшированной сборке.

При установке сборки сначала сравните биты входящей сборки с битами каждой из уже закэшированных сборок и определите, установлена ​​ли уже сборка (если все биты одинаковы, они, очевидно, должны делать одно и то же). Если сборка уже установлена, верните имя ранее кэшированной сборки. Если он еще не установлен, разрешите установку нескольких версий, найдя доступный вариант имени сборки в папке кеша (например, сборка.dll, сборка - (2).dll, сборка - (3).dll и т. д.) , кэшировать сборку в папке и возвращать ее кэшированное имя вызывающей стороне.

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

person Zach Johnson    schedule 07.04.2009