Комментарии 53
Рисунков нет. :(
Спасибо. Как раз некоторое время назад начал изучать System.Addin. Единственное что не нравится — это необходимость жёстко задавать структуру директорий. Я так понимаю, что проблема в том, что в классе-хелпере AddInStore нет возможности изменять названия директорий. Интересно было бы увидеть пример загрузки аддинов без использования AddInStore, если это вообще возможно.
Стоп :) Я только сейчас понял, что Вы говорите о SharpDevelop :)
Статья совсем не о #develop :) Она о новом полезном инструменте для разработчиков, который включён в библиотеку .NET 3.5 ;)
Статья совсем не о #develop :) Она о новом полезном инструменте для разработчиков, который включён в библиотеку .NET 3.5 ;)
НЛО прилетело и опубликовало эту надпись здесь
Напротив, полезно было узнать про этот блок, при случае разберусь :)
НЛО прилетело и опубликовало эту надпись здесь
Невероятно, интересная тема и не перевод.
Но явно не хватает примеров кода, вместо картинок было бы нагляднее.
Но явно не хватает примеров кода, вместо картинок было бы нагляднее.
НЛО прилетело и опубликовало эту надпись здесь
Что имеется в виду под представлением? Я про конкретные классы. Это пользовательские интерфейсы?
Это либо интерфейсы, либо какой-либо наследуемый(возможно абстрактный) класс.
Так, например, Хост видит Addin только через Хост-представление… хотя фактически работает с объектом адаптером, который перенаправляет запросы к контракту, который в свою очереднь перенаправляет их дальше на сторону расширения.
Следующая статья многое прояснит.
Так, например, Хост видит Addin только через Хост-представление… хотя фактически работает с объектом адаптером, который перенаправляет запросы к контракту, который в свою очереднь перенаправляет их дальше на сторону расширения.
Следующая статья многое прояснит.
С нетерпением жду следующей статьи. Пока всё выглядит как что-то очень мутное и непонятное, рассчитанное не менее чем на систему управления шаттлами. :)
Майкрософт всегда так делает.
Ну, не всегда, и в большинстве случаев всегда можно использовать лишь маленький кусок из того, что тебе нужно.
Просто в стандартную библиотеку приходится включать максимально общий и универсальный механизм, иначе обязательно кому-нибудь чего-нибудь не хватит. :)
Но тут уж как-то больно заумно на первый взгляд.
Просто в стандартную библиотеку приходится включать максимально общий и универсальный механизм, иначе обязательно кому-нибудь чего-нибудь не хватит. :)
Но тут уж как-то больно заумно на первый взгляд.
Во всяком случае это не сложнее, чем написать интерфейсы для взаимодействия хоста и add-in'а. Я 3.5 не юзал и вообще как бы не хочу переходить с версии выше 2.0, потому что пора менять технологию на опенсорсную.
Но в 2.0 и 1.1 надо было писать интерфейсы, они точно так же считались контрактами, и посредством рефлекшн, активаторов, доменов приложений и прочего, так же с ними работали. Просто сделали обёртку для всего этого, вот и всё.
Хотя я не знаю, стоит ли ей пользоваться или писать своё, но шатлы то уж винде точно не доверил бы :)
Но в 2.0 и 1.1 надо было писать интерфейсы, они точно так же считались контрактами, и посредством рефлекшн, активаторов, доменов приложений и прочего, так же с ними работали. Просто сделали обёртку для всего этого, вот и всё.
Хотя я не знаю, стоит ли ей пользоваться или писать своё, но шатлы то уж винде точно не доверил бы :)
Если вопрос стоит так, что стоит использовать System.Addin или писать тоже самое, но руками, то тут выбор явно следует сделать в пользу первого. Хотя бы из соображений экономии времени :)
Это как сказать, у каждого способа явно есть преимущества и недостатки, от программиста наверное зависит. Надо по идее рефлектором смотреть, что они там наделали в своей новой дллшке, тогда можно оценить более точно, что наиболее оптимально подходит.
А ещё можно просто обратиться к документации и обойтись без копания исходников :)
Обращение к MSDN не даёт реальной картины. Технология чёрного ящика и если бы он был идеален. Так ведь нет, там такого порой понаписано.
Копание исходников рефлектором — крайность, к которой лично я прибегаю только в том случае, если уже пересмотрена вся документация, а проблема всё ещё не решена… либо когда адекватной доки просто нет.
Я более, чем уверен, что и вы не смотрите реализацию каждого класса рефлектором.
В MSDN есть косяки… но на фоне общего количества информации — эти косяки занимают ничтожно мало места :)
Я более, чем уверен, что и вы не смотрите реализацию каждого класса рефлектором.
В MSDN есть косяки… но на фоне общего количества информации — эти косяки занимают ничтожно мало места :)
Да, про то, что смотреть в исходники не нужно писали в книге «Совершенный код». Вроде как если видишь реализацию, и используешь её особенности в своём коде, в общем, те кто надо прочтут…
Однако я вот такой вот жуткий маньячище. Сначала я открываю Visual Studio разных версий, потом несколько версий MSDN, и сразу после этого несколько копий рефлектора с набором разных библиотек фреймворков.
Однако я вот такой вот жуткий маньячище. Сначала я открываю Visual Studio разных версий, потом несколько версий MSDN, и сразу после этого несколько копий рефлектора с набором разных библиотек фреймворков.
В рефлекторе все равно быстрее, там как правило ты видишь 2-5 сстрочек, и тебе все ясно. А в MSDN у них примеров мало и поэтому втухаешь над каждым абзацем, как над докой по шатлу.
На самом деле, 9/10 кода генерируется с помощью тулзы PipelineBuilder, которая к тому же умеет встраиваться в VS как аддин. Достаточно создать только одну сборку, содержащую контракты. Потом сбилдить её и натравить на получившийся dll-файл PipelineBuilder, после чего мы получим 4 готовые сборки, содержащие представления и адаптеры для обеих сторон взаимодействия.
Managed Extensibility Framework у них поинтереснее будет, как мне кажется. VS10 его будет использовать для расширяемости.
Более подробно на сайте производителя:)
http://msdn.microsoft.com/ru-ru/library/bb384241.aspx
http://msdn.microsoft.com/ru-ru/library/bb384241.aspx
Пробовал пользоваться… запутано все ужасно. Когда разбирался, чуть клавиатуру не съел…
Решили, что проще и намного удобнее написать свое решение в две строчки и не парить мозг)
Решили, что проще и намного удобнее написать свое решение в две строчки и не парить мозг)
Жаль OSGI стандарт и систему плагинов а-ля Eclipse портануть под .Net нельзя
Насколько я понимаю, последующих статей ожидать не стоит?
Не стоит. Используйте MEF и будет счастье. System.Addin, я надеюсь, уйдёт в анналы истории и больше никогда оттуда не вернётся :)
Это зря! MEF и MAF — два разных подхода. MEF не позволяет получить изоляцию (использование AppDomain), а именно это мне и надо и именно это хорошо умеет MAF.
Зачем вообще тогда было писать первую статью?
ystem.Addin is a great technology for addressing issues around versioning resliance, isolation and recoverability.
• Using System.Addin allows you to host different components in separate app domains, thus allowing those addins to have different versions of assemblies which they reference which all run in the same process.
• System.Addin allows you to separately version Addins so that you could have two versions of an Addin sitting side by side.
• System.Addin manages automatically unloading app-domains they are no longer used thus allowing you reclaim memory.
• System.Addin has a bunch of security infrastructure (addins run in a sandbox) to ensure that components that are loaded do not have unauthorized access to data in the rest of the app.
• System.AddIn allows your app to gracefully recover whenever one of the addins crashes (this is due to isolation)
MEF on the other hand is a great technology for discovery and composition
• MEF composes deep object hierarchies of components
• MEF abstracts components from static dependencies.
• MEF can allow components to be lazily loaded and lazily instantiated.
• MEF provides a cataloging mechanism and rich metadata for components to allow them to dynamically discovered.
• MEF can compose components from various programming models, it is not bound to static types.
Зачем вообще тогда было писать первую статью?
Выше в каментах я уже писал о том, что это два разных подхода. Тут вопросов нет.
По личному опыту — случаев, когда необходимо использовать System.Addin — мало. Геморроя связанного со спецификой AppDomain — много, но иногда он оправдан.
Посему… начав писать демо для второй статьи, и посчитав впоследствии это всё неинтересным, я забил на неё…
По личному опыту — случаев, когда необходимо использовать System.Addin — мало. Геморроя связанного со спецификой AppDomain — много, но иногда он оправдан.
Посему… начав писать демо для второй статьи, и посчитав впоследствии это всё неинтересным, я забил на неё…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
System.Addin или «Игры с надёжными плагинами». Часть 1