Как стать автором
Обновить

Комментарии 53

Рисунков нет. :(
Сорри… поправил… сейчас вроде как должно быть всё хорошо.
Опять нет рисунков. Перезалейте на habrastorage.
Спасибо. Как раз некоторое время назад начал изучать System.Addin. Единственное что не нравится — это необходимость жёстко задавать структуру директорий. Я так понимаю, что проблема в том, что в классе-хелпере AddInStore нет возможности изменять названия директорий. Интересно было бы увидеть пример загрузки аддинов без использования AddInStore, если это вообще возможно.
#develop? Его архитектура вообще не предполагает полезного функционала вне addin'ов :)
Почему же не предполагает?) Хост-приложение может быть обычным Stand-alone приложением :) Может так же по-старому цеплять плагины через Reflection или вообще работать без всяких расширений :)
Хост у них и так standalone. Был в версии 1.0, по крайней мере :) Тем не менее, функционал вне addin'ов у них считается (считался?) дурным тоном.
Скорее всего, мои познания о внутренностях #develop уже устарели — в той мере, в какой устарела «Dissecting a C# Application: Inside SharpDevelop» :)
Поковырялся рефлектором и понял что без AddInStore ничего не получится… Жаль.
Стоп :) Я только сейчас понял, что Вы говорите о SharpDevelop :)
Статья совсем не о #develop :) Она о новом полезном инструменте для разработчиков, который включён в библиотеку .NET 3.5 ;)
Блин… промахнулся с ответом… извиняйте :) Я тут новичок) Не привык ещё)
НЛО прилетело и опубликовало эту надпись здесь
Напротив, полезно было узнать про этот блок, при случае разберусь :)
НЛО прилетело и опубликовало эту надпись здесь
Невероятно, интересная тема и не перевод.
Но явно не хватает примеров кода, вместо картинок было бы нагляднее.
Не хотелось, чтобы статья получилась длинной… следующая будет как раз демонстрировать пример :)
НЛО прилетело и опубликовало эту надпись здесь
Это часть .NET 3.5, но вынесен из System.Core.dll в отдельную сборку System.AddIn.dll.
Что имеется в виду под представлением? Я про конкретные классы. Это пользовательские интерфейсы?
Это либо интерфейсы, либо какой-либо наследуемый(возможно абстрактный) класс.
Так, например, Хост видит Addin только через Хост-представление… хотя фактически работает с объектом адаптером, который перенаправляет запросы к контракту, который в свою очереднь перенаправляет их дальше на сторону расширения.

Следующая статья многое прояснит.
Странно, что они контракты представлениями назвали. Ладно, подожду следующей статьи :-D
Ну «представление» — это мой вольный перевод слова view :)
С нетерпением жду следующей статьи. Пока всё выглядит как что-то очень мутное и непонятное, рассчитанное не менее чем на систему управления шаттлами. :)
Майкрософт всегда так делает.
Ну, не всегда, и в большинстве случаев всегда можно использовать лишь маленький кусок из того, что тебе нужно.
Просто в стандартную библиотеку приходится включать максимально общий и универсальный механизм, иначе обязательно кому-нибудь чего-нибудь не хватит. :)

Но тут уж как-то больно заумно на первый взгляд.
Во всяком случае это не сложнее, чем написать интерфейсы для взаимодействия хоста и add-in'а. Я 3.5 не юзал и вообще как бы не хочу переходить с версии выше 2.0, потому что пора менять технологию на опенсорсную.

Но в 2.0 и 1.1 надо было писать интерфейсы, они точно так же считались контрактами, и посредством рефлекшн, активаторов, доменов приложений и прочего, так же с ними работали. Просто сделали обёртку для всего этого, вот и всё.

Хотя я не знаю, стоит ли ей пользоваться или писать своё, но шатлы то уж винде точно не доверил бы :)
Если вопрос стоит так, что стоит использовать System.Addin или писать тоже самое, но руками, то тут выбор явно следует сделать в пользу первого. Хотя бы из соображений экономии времени :)
Это как сказать, у каждого способа явно есть преимущества и недостатки, от программиста наверное зависит. Надо по идее рефлектором смотреть, что они там наделали в своей новой дллшке, тогда можно оценить более точно, что наиболее оптимально подходит.
А ещё можно просто обратиться к документации и обойтись без копания исходников :)
Обращение к MSDN не даёт реальной картины. Технология чёрного ящика и если бы он был идеален. Так ведь нет, там такого порой понаписано.
Копание исходников рефлектором — крайность, к которой лично я прибегаю только в том случае, если уже пересмотрена вся документация, а проблема всё ещё не решена… либо когда адекватной доки просто нет.

Я более, чем уверен, что и вы не смотрите реализацию каждого класса рефлектором.
В MSDN есть косяки… но на фоне общего количества информации — эти косяки занимают ничтожно мало места :)
Да, про то, что смотреть в исходники не нужно писали в книге «Совершенный код». Вроде как если видишь реализацию, и используешь её особенности в своём коде, в общем, те кто надо прочтут…

Однако я вот такой вот жуткий маньячище. Сначала я открываю Visual Studio разных версий, потом несколько версий MSDN, и сразу после этого несколько копий рефлектора с набором разных библиотек фреймворков.
У каждого свой стиль ;)
В рефлекторе все равно быстрее, там как правило ты видишь 2-5 сстрочек, и тебе все ясно. А в MSDN у них примеров мало и поэтому втухаешь над каждым абзацем, как над докой по шатлу.
На вкус и цвет, опять же… лично я сомневаюсь в эффективности разработки с одним только рефлектором под руками и без MSDN…
На самом деле, 9/10 кода генерируется с помощью тулзы PipelineBuilder, которая к тому же умеет встраиваться в VS как аддин. Достаточно создать только одну сборку, содержащую контракты. Потом сбилдить её и натравить на получившийся dll-файл PipelineBuilder, после чего мы получим 4 готовые сборки, содержащие представления и адаптеры для обеих сторон взаимодействия.
Именно так :)
Managed Extensibility Framework у них поинтереснее будет, как мне кажется. VS10 его будет использовать для расширяемости.
На самом деле публикация нескольких статей по MEF была у меня в планах после завершения цикла статей про System.Addin :)
Это что, история Linq2Sql -> Entity Framwork повторяется? Сначала сделаем быстро и эффективно, а потом заумно и тормозно.
Не смотря на то, что MEF и System.Addin вроде бы как служат для одной цели — они разные. Просто разные. У каждого из них есть свои фишки, которых нет у другого…
Пробовал пользоваться… запутано все ужасно. Когда разбирался, чуть клавиатуру не съел…

Решили, что проще и намного удобнее написать свое решение в две строчки и не парить мозг)
Если не секрет, какими возможностями обладает «решение в две строчки»? :)
Одной. Умеет загружать длл'ки из папки плагинс. То, что нужно.
Помнится, когда пробовал сабж, в солюшене было с полдесятка абсолютно левых проектов с либами каких-то контрактов, адаптеров… Так нельзя делать по-моему.
System.Addin разрабатывался для несколько других сценариев…
Жаль OSGI стандарт и систему плагинов а-ля Eclipse портануть под .Net нельзя
Опыт показывает, что возможно всё.
Вопрос только в том, сколько времени это займёт :)
там концептуальная проблема…

— Сборки загруженные в одном домене выгружать нельзя.
— Загружая в разные домены имеем нехилый оверхед на ремоутинг.
в блоге команды CLR Addins Джесс Каплан, если мне память не изменяет, писал статейку, в которой делался вывод о том, что оверхед не такой уж и страшный при использовании System.Addin. In-domain, Cross-domain и Cross-process сценарии сравнивались.
Насколько я понимаю, последующих статей ожидать не стоит?
Не стоит. Используйте 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 — много, но иногда он оправдан.

Посему… начав писать демо для второй статьи, и посчитав впоследствии это всё неинтересным, я забил на неё…
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.