Задачки на подумать
Что то смотрю скучно стало. Решил подкинуть задачек из списка "решить когда нибудь".
Итак, есть некая система использующая принцип "плагинов" - динамически подгружаемых библиотек, которые в свою очередь пользуют общие библиотеки.
Например: П1 пользует Б1, Б2 и Б3, П2 пользует Б1 и Б3. Прога пользует Б1 и Б2.
1. Когда всё располагается в одном каталоге с прогой и компилируется одновременно, никаких проблем пока нет. Но хочется, чтобы при обновлении проги не нужно было обновлять старые плагины. Варианты?
2. У плагинов есть различные параметры настройки, которые должны отображатся в общем окне настроек приложения. Использование UserControl для WinForms в интерфейсе плагина решает задачу для WinForms. Но хочется чтобы плагины можно было пользовать и для WPF, либо пользовать окошки WPF в WinForms. При этом хотелось что бы параметры настройки остались личным делом плагина. Что же тогда передавать в интерефейсе плагина, что было проще использовать?
Предполагемые решения специально не привожу, может что более интересное найдётся.
1. Б1, Б2, Б3 - компилируется и апдейтятся вместе прогой. Плугины - они должны быть небольшими - грузятся и активируются по имени либы. Если совсем "правильно" - вешаем на класс аттрибутик и фильтруем по ним...
Код - могу сбросить позднее...
2. Не знаю - ВПФ - мимо...
Код - могу сбросить позднее
По постановке задачи вопросы есть?
Проблема не как сделать систему плагинов (там как раз по атрибуту и по принципу SOA), а как обеспечить взаимозаменяемость отдельных частей.
Ну типа, год назад поставили систему и все либы имели версию 1.0, а теперь парочка имеет версию 1.5 и требуется обновить ехе на меняя плагинов. Либо нужно только плагин обновить не меняя ехе и другой плагин.
2. Не знаю - ВПФ - мимо...
Это не важно, считай ASP.NET. Плагин хочется иметь платформно-независимым. Но приложение должно пользовать только вызов интерфейса плагина.
Еще одну вспомнил
3. Как отличить манагед от unmanged DLL без exception?
1. Когда всё располагается в одном каталоге с прогой и компилируется одновременно, никаких проблем пока нет. Но хочется, чтобы при обновлении проги не нужно было обновлять старые плагины. Варианты?
Мне кажется, Вы слишком вольно решили интерпретировать термин plug-in. Если Вы должны все компилировать вкуче, то это - вообще не плагин.
Плагин - это нечто, что Вы можете установить, не останавливая приложения. Но я уверен, Вы знаете, что такое плагин не хуже меня, но лучше придумайте другое слово, а то с толку сбивает.
Кроме того, плагин не обязательно имеет какое-то отношение к GUI, так что WinForms и WPF тоже - лишние детали в контексте плагинов.
Либо нужно только плагин обновить не меняя ехе и другой плагин.
-----
Пока не вижу что мешает.
У меня плугины делаются для двух версий 7-й и 11-й. Ожидается еще 17-я. Плугины лежат кучкой в отдельной папке.
Загрузчик плугинов читает заголовки и выбирает соответствующие версии,
Сколько их папке и какие именно - загрузчику без разницы - выберет подходящие по версии.
Объекты с которыми плугины работают - в отдельных ддлках вместе с ехе. Когда вносил изменения уже забыл - там все сделано по докам. Появится еще версия - напишу еще одну дллку.
Соответственно замена никакой проблемы не представляет - могу менять ехе, могу - плугины. Иногда так и делается - ручками закинул и ладно.
Ах, да... В проекте ссылок на плугины в референсах нет. Есть ссылки дллки плугинов как на файлы. Я вроде писал года полтора-два назад...
Или тебя деплоймент по частям интересует? Я это не смотрел, но никой проблемы нет - лишь бы плугин был доступен - загрузчик дллки может и не лочить...
все либы имели версию 1.0, а теперь парочка имеет версию 1.5
------
Единственная проблема - когда твои Б1, Б2, Б3 не совместимы или с ЕХЕ, или с плугинами - ну тут уже никак... На этот случай - имплементировано все через интерфейсы - пока они совпадают - все нормально.
Плагин хочется иметь платформно-независимым.
-----
Угу... но вин-форм и веб-форм несколько различаются по месту исполнения кода и хранения информации - реализация довольно различная...
3. Заголовок читать? Но Я не смотрел в чем там разница...
но лучше придумайте другое слово
ничего попроще, покороче и понятней не придумывается. Есть предложения?
Плагин - это нечто, что Вы можете установить, не останавливая приложения
В принципе так оно и есть, но где то все равно нужно держать общие аттрибуты и интерфейсы. И делать один единственный файл/проект со ссылками на целые либы, как то не очень...
так что WinForms и WPF тоже - лишние детали в контексте плагинов
Если писать только абстрактно - могут не понять, поэтому детали ввёл специально.
Плагин - это нечто, что Вы можете установить, не останавливая приложения.
-----
Не обязательно.
Возможность заменить дллку плугина зависит не от дллки, а от того каким методом она загружена.
Аналогично - выгрузка - от того как используется объекты из дллки - пока есть живые ссылки - не выгрузишь.
Так что плугин стоит определять как элемент, отсутствие которого не ведет к неработоспособности программы.
Пока не вижу что мешает.
Если плагин один единственный файл то ничего. Но предположим, два плагина пользуют либку для СОМ порта, а эти либки пользуют еще одну самую общую либку которую пользует и ехе.
При загрузке плагины попадают в аппликатион домаин со всеми либками. А там низзя держать одинаковые типы с разными версиями.
Поставили софт с версиями либок 1.0 пару лет назад. Теперь нужно один плагин заменить, а у него уже все общие либки другой версии 1.5
Значит один плагин пользует СОМ либку 1.0, а другой 1.5.
На этот случай - имплементировано все через интерфейсы - пока они совпадают - все нормально
не все может быть через интерфейсы, да даже пусть и так, но один и тот же тип будет иметь разную имплементацию, то бишь нужно раскидывать по разным апп-доменам.
но вин-форм и веб-форм несколько различаются по месту исполнения кода и хранения информации
безусловно и в этом то и есть проблема. Приложение не должно знать о настройках плагина они привязаны к плагину и только он знает как их отобразить пользователю в наиболее удобном виде. Конечно, для каждой платформы должна быть своя имплементация и вот ее то и нужно как то удобно абстрагировать.
3. Заголовок читать?
Да видимо прийдется, хотя очень не хотелось
А вы уверены что не изобретаете велосипед? Я плохо знаком с С#, но осталось в голове что есть для него от микрософта MAF, который "похож" на явовский OSGi, который ваши требования (в яве) выполняет.
При загрузке плагины попадают в аппликатион домаин
-----
Ну тут уже без деталей имплементации загрузчика не обойтись.
Такую задницу Я себе пока еще не создавал, но одноименные классы из разных дллок вроде уже инстанцировал,
Теперь нужно один плагин заменить, а у него уже все общие либки другой версии 1.5
-----
Ты еще попроси что бы и либы 1.5 на систему не копировались - тогда веселее будет.
Делаешь общую либу с интерфейсами. Пока все взаимодействует через них - проблемы не будет.
Если уж совсем выпал из синхронизации - замени и ехешник.
один и тот же тип будет иметь разную имплементацию, то бишь нужно раскидывать по разным апп-доменам
------
Это если ты грузишь стандартным способом по имени дллки.
Попробуй грузить из байт-массива.
вот ее то и нужно
как то удобно абстрагировать.
-----
Поделись как нарисуешь - Я ее в шаблоны загоню и забуду про различия в протоколах...
Замечательный ответ! Как раз согнать с рельсов. Всегда пользовали MEF. Да и в принципе реализовывался совсем другой концепт, а задачка получилась как бы по пути.
https://stackoverflow.com/questions/835182/choosing-betwee...
Надо попробовать, хотя народ грит что сильно сложный концепт.
но одноименные классы из разных дллок вроде уже инстанцировал
И куда они попадали после загрузки, и насколько сложной была иерархия классов?
Пока все взаимодействует через них - проблемы не будет.
Тут позволю не согласится. Вот в интерфейсе есть функция Run. В версии 1.0 она зажигает лампочку, а вот в версии 1.5 дополнительно еще и окно открывает (ошибка).
Сделал ты обновление в цех, а тебе звонят и говорят что толщина стекла не мерятся. А если бы плагин измерения толщины не менялся бы вообще (даже не перекомпилировался), то можно было сразу сказать что проблема у них. А так изменения в общей либе вполне могут затронуть что то "дружественное", то бишь тестить нужно опять по полной.
Попробуй грузить из байт-массива.
А разница то в чем? The assembly is loaded into the application domain of the caller.
https://msdn.microsoft.com/en-us/library/h538bck7(v=vs.110...
Поделись как нарисуешь
нет проблем, только как я уже сказал, задачки на будущее, когда время будет на их реализацию неясно.
Сейчас нужно совсем в другую сторону рыть - промышленный Ethernet
Сегодня долбил целый день контроллер от Сименса, а его ИП так и не нашел.
И куда они попадали после загрузки, и насколько сложной была иерархия классов?
-----
Куда попадали - не смотрел - без надобности было.
Иерархия, по классам, двух- и трех- уровневая. Все классы в иерархии - в пределах одной либы.
то бишь тестить нужно опять по полной.
-----
Ну так не путай две вещи - технику загрузки дллки и функциональность в дллке.
Первое мы можем обсуждать на уровне нашего опыта и знаний системы, а вот по второму знания только у тебя.
И это - про совместимость Я оговорил ранее - либо есть, либо нету.
тебе звонят и говорят что толщина стекла не мерятся.
-----
Ну и? Ну горит лямпочка - ошибка... ну дополнительно показал формочку - ошибка... стекло-то меряется не тут...
Сейчас как раз ковыряю именно меряющий код... 4-ре месяца назад все приостановили на средине модификации...
сейчас - снова возвратили... мрачно, однако...
А разница то в чем?
-----
Первая разница в том, что у тебя не лочится либа. Т.е. ты не оказываешься в ситуации, когда информация об составе либы полностью кешируется и создает проблемы. Хотя - может и не так...
долбил целый день контроллер от Сименса, а его ИП так и не нашел
-----
Когда-то ковырял Симатик от Сименса - не было там ИПов - там была своя идентификация контроллеров.
Все классы в иерархии - в пределах одной либы.
У нас обычно в разных. Базовая функциональность в общей, а конкретика в специализированной.
Первое мы можем обсуждать на уровне нашего опыта и знаний системы, а вот по второму знания только у тебя.
неа. Конкретика везде только у исполнителя, а вот принцип остается общим для всех.
Даже то что ты говорил о неизменности интерфейса это тоже может быть верно при определенном концепте. Мне то ведь ничто не мешает добавить новый интерфейс не меняя старого.
Просто ты не учитываешь еще одной вещи - даже используя одинаковые штекера нужно иметь одинаковые сигналы. Может измениться даже просто время отклика и это может повлечь изменения в работе проги.
Симатик от Сименса - не было там ИПов
Есть там всё просто они могут быть "прозрачными", так как работа начинается с броадкаста "а есть тут кто?".
Хотя это так в нашей системе.
У нас обычно в разных.
-----
Как повлияет на ситуацию - не знаю - надо тестить. Потому и подчеркнул что все в одном месте.
Мне то ведь ничто не мешает добавить новый интерфейс не меняя старого.
-----
Ну сознательно теряешь совместимость - нормальная практика.
Ненормальная практика - продолжать требовать совместимости в условиях когда она сознательно утрачена.
Просто ты не учитываешь еще одной вещи - даже используя одинаковые штекера нужно иметь одинаковые сигналы. Может измениться даже просто время отклика и это может повлечь изменения в работе проги.
-----
Разумеется - обсуждается - софт, а не детали аппаратной реализации незнамо чего.
То, что могут возникнуть проблемы из-за деталей внешних подключений - это плохо. Сильно плохо. Чем решать - надо смотреть по месту, но в общем случае периферия должна общаться с системой по одному из стандартных протоколов и прием/передача должны ему соответствовать.
Хотя это так в нашей системе.
-----
Ну так это в вашей системе. 
Мне то ведь ничто не мешает добавить новый интерфейс не меняя старого.-----Ну сознательно теряешь совместимость
ничего подобного. Старый код не должен знать о новой функциональности, но продолжает спокойно работать. Именно то что и требуется
Разумеется - обсуждается - софт, а не детали аппаратной реализации незнамо чего.
Примерчик со штекером просто аналогия интерфейса и его имплементации.
Ты утверждаешь, что достаточно не менять интерфейса и всё будет хорошо. Я же говорю, что это недостаточное условие.
Была у меня как то либа с хорошим тестовым покрытием. Так бывало самые "безобидные" изменения приводили к сбою совсем не связанных вроде тестов.
но продолжает спокойно работать.
-----
Ну а новый код со старой либой вываливается с криком - неимплементировано...
Мне вот сейчас надо будет имплементить новый IEnumerator<T>
Такой, чтобы умел положить текущий элемент на вершинку треад-статического стека в потоке. А если там такой уже есть - заменил его.
И ты хочешь, чтобы он без сбоев работал при отсутствии стека?
А вот как прописать обязательность наличия - не представляю...
Так бывало самые "безобидные" изменения приводили к сбою совсем не связанных вроде тестов.
-----
Угу... бывало и по-другому - сбои в разные моменты и без всякого изменения в коде...
Но мы же не глюки обсуждаем, а как обновить плагины когда у них перехлест в используемых дллках?
Ну а новый код со старой либой вываливается с криком - неимплементировано
Не вываливается, а просто говорит что неимплементировано. То бишь нефиг меня трогать для новых работ.
Но в моем случае это не важно. У меня следующий случай:
1. Система поставлена заказчику Б в комбинации А.
2. Требуется заменить заказчику минимально возможный набор компонентнов из комбинации А.
Но мы же не глюки обсуждаем, а как обновить плагины когда у них перехлест в используемых дллках?
Не совсем. Меня лично интересует архитектура построения системы с минимальной зависимостью между частями при наличии общих библиотек.
с минимальной зависимостью между частями при наличии общих библиотек.
-----
Переформулировать не хочешь? Бо в этом варианте это точно не 1 по формулировке.
В общем случае, как ты и говорил выше, несовместимые либы грузятся в другой аппдомен.
Я бы не мучался и сделал первичную загрузку плугинов в аппдомен для конкретной версии - тогда голова не будет болеть вопросом Куда грузить?
Переформулировать не хочешь?
ну завтра опять не на работу можно и подлинее написать. В одно предложение не получится, да и проблема достаточно обширная. Я и так ее сократил по минимуму.
1. Есть необходимость относительно часто создавать новые проекты, которые имеют общие части.
2. Для этого потихоньку создается требуемая библиотека модулей/классов/суб систем (не знаю как лучше назвать, как то не интересовало). Все модули можно разделить на группы: части которые нужны/можно использовать абсолютно для всех проектов, части которые пользует только какая то часть проектов (коммуникация по СОМ порту, например) но классы относительно универсальные и группа специфическая (типа весов производителя А с обменом по СОМ порту). Групп не точно 3, но принцип разбиение остается одинаков.
3. Есть проект который собирается из этих модулей. Пока использовалась только статическая линковка и все либы располагались в каталоге с ехе.
Если в прямоугольниках тексты заменить на другие то получатеся что то типа этого
https://qph.ec.quoracdn.net/main-qimg-ec0ec1d51f85f9c456f1...
4. Планируется специфические модули (типа весов производителя А с обменом по СОМ порту) переписать для использования с динамической линковкой к проекту.
Но каждый специфический модуль использует другие модули общие для всех.
Если рассматривать одну временную точку то можно без проблем закинуть новый модуль простым копированием.
В принципе, если не пользовать общие модули как библиотеки, а пользовать ссылки прямо на исходные файлы, то в результате получим после компиляции один единствееный модуль и проблема для полльзователей автоматом исчезнет, но появятся новые проблемы у разработчиков.
5. Проблемы появляются как только хочется менять модули в различное время, при
этом они будут иметь различные версии общих библиотек.
глянул я ентот MAF понятно отчего его мало кто пользует.
https://www.codeproject.com/articles/25866/addin-enabled-a...
"the 7 (minimum) components that are required in order to correctly setup an AddIn model enabled application"
"The AddIn model relies on a strict directory structure."
Ok AddIns понятно, хотя и имя другое хочется. Но еще 4 в дополнение 
Здравствуйте.
Не нашел другого места, где попросить помощи. Извините, что влез к вам. Но название темы как нельзя к моему вопросу.
Хочу попробовать сделать дома миниАТС с выходом на стационарную линию, но вместо ДЕКТ трубок использовать сотовые телефоны членов семьи. Это можно сделать программными приложениями (допустим Роутер с Openwrt+Asterisk и Voip шлюзом).
Но к сожалению знаний и времени разобраться в том, как это сделать не хватает. Случайно наткнулся на приложение Fritz!Fon APP позволяющую подключать сотовые к базе Fritz!Box.
У меня нет модема Fritz!Box, поэтому как это работает я не знаю. И вообще я живу за пределами Германии, поэтому мне не доступны ваши возможности телефонии и интернета.
Из переписки с одним человеком выяснил, что можно подключить несколько сотовых трубок. Но у него они работают неполноценно как ДЕКТ. Просто все одновременно звонят когда идет входящий на городской номер и позволяют позвонить через городскую линию.
Но раз их можно подключить, то скорее всего в конфигах программного обеспечения роутера Fritz!Box, руками можно их прописать как–будто это ДЕКТ трубки. Тогда они начнут выполнять функции полноценного ДЕКТ телефона миниАТС.
Поэтому прошу людей, немного разбирающихся в программировании и владеющих Fritz!Box, проверить мои предположения.
Мне казалось, что для этого придумали GAC...
Но хочется, чтобы при обновлении проги не нужно было обновлять старые плагины. Варианты?
Не нарушать обратную совместимость :)
При этом хотелось что бы параметры настройки остались личным делом плагина. Что же тогда передавать в интерефейсе плагина, что было проще использовать?
Ничего. Плагин сам должен уметь находить свои настроийки. Делаешь дерево <my plugin>\<version>\настройки. Хранить можешь хоть в реестре, хоть на диске. При этом, если надо, можешь даже в юзерском профайле хранить или для всей системы (ну или микс).
А плагин получит все данные через рефлекшен.
А главной проге в манифесте просто указываешь с какими версиями плагина она умеет работать. Все :)
Мне казалось, что для этого придумали GAC...
Для чего? Чтобы каждый кому не лень кидал туда свои либы?
Но хочется, чтобы при обновлении проги не нужно было обновлять старые плагины. Варианты? -- Не нарушать обратную совместимость :)
Вероятно я плохо проблему описал. 
Совместимость не нарушается. Просто плагины состоят из нескольких библиотек. Плагин1 пользует Б1 и Б2, плагин2 пользует Б2. Прога также пользует Б2. Если даже изменить коммент в Б2 студия перестроит всё и приложение и плагин1 и плагин2. Хотя даже если просто заменить Б2, то согласно Black-box testing нужно перепроверить полную цепочку. Мы ведь "не знаем", что менялось в Б2.
Ну и кроме того, в большом проекте совместимость иногда приходится нарушать.
И еще - вы с "подписанными либами" работали?
Плагин сам должен уметь находить свои настроийки
Именно это он и умеет, но есть одна маленькая проблемка - пользователь их должнен менять через GUI.
А главной проге в манифесте просто указываешь с какими версиями плагина она умеет работать.
Так в тот то и смысл, чтобы прога ничего не знала о плагинах, кинул что новое - взяла и подхватила или сказала сорри, слишком молод.
Не нашел другого места, где попросить помощи.
Не там искали, ваша проблема к программированию почти что не относится. Это скорее в "Интернет" https://foren.germany.ru/telecommunication.html?Cat=
поэтому как это работает я не знаю.
Открывается VPN соединение с фрицем и черех него идёт VOIP на выделенное во фрице устройство-телефон. Как и ДЕКТ телефону ему можно назначить номер.
https://www.tecchannel.de/g/avm-fritz-app-fon,37406,37#gal...
Но у него они работают неполноценно как ДЕКТ
А как должно быть полноценно если есть только один номер для пользования?
Для чего? Чтобы каждый кому не лень кидал туда свои либы
Именно так. Ну не просто либы, а расшаренные либы. В твоем примере ниже Б2 - как раз идеально подходит для GAC.
Если даже изменить коммент в Б2 студия перестроит всё и приложение и плагин1 и плагин2. Хотя даже если просто заменить Б2, то согласно Black-box testing нужно перепроверить полную цепочку. Мы ведь "не знаем", что менялось в Б2.
Ну так ты раздели все это на 4 независимых компоненты: приложение, плагин1, плагин2 и Б2. У тебя получится 2 уровня - на нижнем уровне Б2, на верхнем приложение и плагины. Ну а дальше надо ввести простое правило - верхнии уровни используют только релизнутые компоненты. Таким образом Б2 никогда не будет перекомпилироваться, а работоспособность компоненты гарантируется процессом релиза.
Да, я понимаю, что такая перестройка сделает разработку более долгой. И да, я понимаю, что начальство будет возражать :) Но я не знаю другого более или менее надежного способа. Если собирать все мнесте, то косяки будут всплывать постоянно. Так что нужно отделять разработку компонент от разработки продуктов.
Мы ведь "не знаем", что менялось в Б2.
Нельзя объять необъятное. Также как нельзя гонять 100500 тестов при каждом изменении комментариев.
Ну и кроме того, в большом проекте совместимость иногда приходится нарушать.
Конечно, тут надо уже искать решение для кажного конкретного случая.
И еще - вы с "подписанными либами" работали?
В GAC неподписанным нельзя :)
Именно это он и умеет, но есть одна маленькая проблемка - пользователь их должнен менять через GUI.
Почему это проблемка?
Так в тот то и смысл, чтобы прога ничего не знала о плагинах, кинул что новое - взяла и подхватила или сказала сорри, слишком молод.
Помню, мы делали расширение для FinalBuilder'а, так при установке нашего расширения мы патчили ему app.config :D Впрочем, можно, это не самое лучшее решение :D
В твоем примере ниже Б2 - как раз идеально подходит для GAC.
As a general guideline, keep assembly dependencies private, and locate assemblies in the application directory unless sharing an assembly is explicitly required.
Не устаю ругаться, на тех кто засовывает свои либы в GAC, постоянно только проблемы при каждом обновлении, которые просто не найти.
Установка/Удаление/Проверка, права админа и пр. дополнительная морока. Потом не забываем, это чисто в примере 1 либа, а на самом деле их гораздо больше. Причем, то что нужно для одного проекта, совсем не нужно для другого. Что будет на компе разработчика в GACе после полугода
Ну а дальше надо ввести простое правило - верхнии уровни используют только релизнутые компоненты. ...а работоспособность компоненты гарантируется процессом релиза
Есть такой волшебный процесс?
Так что нужно отделять разработку компонент от разработки продуктов
А еще отделять разработку "мелких" компонент от более "крупных".
Также как нельзя гонять 100500 тестов при каждом изменении комментариев
Кто будет постоянно объяснять CI что менялись чисто комменты и чтобы он замолк на ночь в этот раз. А как насчет того, что "незначительные изменения" могут привести к сбоям в других системах.... А как насчёт того, что оборудование есть только у клиента и нормальные тесты вообще нельзя провести?
тут надо уже искать решение для каждого конкретного случая
Как раз то и хочется найти решение для всех случаев. Ну или хотя бы для большинства стандартных. При релизе "думать" низзя. Особенно когда у клиентов непрерывное производство.
Именно это он и умеет, но есть одна маленькая проблемка - пользователь их должнен менять через GUI.---Почему это проблемка?
Потому что плагин должен иметь GUI. А плагины можно пользовать из Winforms или WPF, а при тестах и консолью попользоваться.
As a general guideline, keep assembly dependencies private, and locate assemblies in the application directory unless sharing an assembly is explicitly required.
Это как раз твой случай: продукт, плагин1 и плагин2 - независимые друг от друга продукты (особенно плагин1 и плагин2).
Не устаю ругаться, на тех кто засовывает свои либы в GAC, постоянно только проблемы при каждом обновлении, которые просто не найти.
Какие проблемы? Каждая библиотека имеет свою версию и подпись.
Установка/Удаление/Проверка, права админа и пр. дополнительная морока.
Ты там велосипед изобретаешь? Установка, удаление, права, а также reference counter - все это умеет делать MSI.
Что будет на компе разработчика в GACе после полугода
Все зависит от того, как ты сделаешь установку. Если сделаешь все правильно, то проблем с ГАКом не будет.
Есть такой волшебный процесс?
Каждый придумывает себе свое :) Но вообще надо исходить из того,
что релизнутое уже не меняется и не имеет багов. (понятно, что баги есть везде, но ты тестируешь свой продукт, а не компоненту более низкого уровня)
А еще отделять разработку "мелких" компонент от более "крупных".
Размер компонент тут не важен. Тут важны уровни. И уровней этих может быть много. Очевидно, что чем больше уровней, тем дольше новшество будет доходить до верхних компонент. Но с другой стороны такой подход повышает надежность.
Как раз то и хочется найти решение для всех случаев.
Золотого грааля не существует ;)
При релизе "думать" низзя. Особенно когда у клиентов непрерывное производство.
Думают об этом либо при релизе, либо в момент, когда нарушают обратную совместимость. При чем тут непрерывное производство у клиентов? За "подгон" системы отвечает инсталлятор.
Потому что плагин должен иметь GUI. А плагины можно пользовать из Winforms или WPF, а при тестах и консолью попользоваться.
Ну во-первых, можно делать GUI тесты. В том числе и автомаризированные.
во-вторых, надо четко понимать, что именно ты хочешь протестировать. я не могу вот так с лету придумать случай, когда для тестирования функционала нужен GUI.
Это как раз твой случай: продукт, плагин1 и плагин2 - независимые друг от друга продукты (особенно плагин1 и плагин2).
unless sharing an assembly is explicitly required. Не вижу никакого случая, чтобы делать енто всё общим на машину.
Какие проблемы? Каждая библиотека имеет свою версию и подпись.
Какие именно проблемы не разбирался - софт работал не правильно, лечится переустановкой с полным удалением всех версий из GACа
Ты там велосипед изобретаешь? Установка, удаление, права, а также reference counter - все это умеет делать MSI.
Для начала, микрософтовского инсталлера нет и будет. Когда-то хотели только его и пользовать, начали усиленно тестить и пришли к случаю, что прогу ни удалить ни установить по новой.
Но даже не это проблема. Чтобы потестить приложение нужно его обязательно установить и удалить все локальные либы чтобы они не подхватились случайно. Иногда также бывает что при сборке на компе другого разработчика упрямо подхватываются старые либы, сейчас хоть ошибка лезет что такой либы нет, а так просто подхватится и всё.
Кроме того сейчас можно достаточно просто вывести список всех локальных файлов, что вместе с ехе живут. А так прийдется извращаться.
Также пользователи обычно не имеют прав админа, так что обновление возможно только в заранее оговоренный каталог. Да многое еще чего можно найти.
Если сделаешь все правильно, то проблем с ГАКом не будет.
Так видимо думают всё кто этой гадостью занимается, а проблемы случаются. Это я про других, если что
Золотого грааля не существует ;)
Безусловно,только текст был несколько длинее и смысл был несколько иным. Нужно не идеальное решение, а оптимальное для нашего конкретного случая.
Думают об этом либо при релизе, либо в момент, когда нарушают обратную совместимость
Ну уже вроде говорил про "обратную совместимость" - дело никак ни в этом.
При чем тут непрерывное производство у клиентов?
Это "прелесть" нужно хоть раз попробовать, а то описывать времени уже нет. Коротко - стресс неимоверный, всё можно делать только на автомате в очень ограниченное время.
За "подгон" системы отвечает инсталлятор.
За подгон системы отвечает фирма разработчик 
, ничего инсталлировать низзя, только заменить содержимое одного каталога. Причем всё удаленно. А когда гулял вирус, так и удалёнку прикрыли.
Ну во-первых, можно делать GUI тесты.
Для начала проблема не в тестах, а в реализации выдачи GUI наружу (и не в качестве модального диалога).
А для тестов GUI было бы интересно узнать решение для винформс и контролов сторонних разработчиков.
я не могу вот так с лету придумать случай, когда для тестирования функционала нужен GUI.
Это смотря какие цели ставить. Вот при нажатии на меню Открыть и на кнопку открыть будет открываться окошко? Это будет тоже самое окошко? А что будет если будет нажато Ок или Отменить?
Не вижу никакого случая, чтобы делать енто всё общим на машину.
Собственно говоря, есть 2 способа: 1) самостоятельно запились менеджер загжаемых библиотек или 2) использовать имеющийся механизм.
Написать самостоятельно - не так уж и сложно, но это дополнительный код который надо тестировать.
Я лично не вижу принципиальной разницы.
Для начала, микрософтовского инсталлера нет и будет
Ну сами себе злобные Буратины :) Просто для интереса, а что вы используете?
Когда-то хотели только его и пользовать, начали усиленно тестить и пришли к случаю, что прогу ни удалить ни установить по новой.
Вы просто не умеете его готовить :) Наверняка нарушали "правило компонентов" ;)
Кроме того сейчас можно достаточно просто вывести список всех локальных файлов, что вместе с ехе живут. А так прийдется извращаться.
Вот это вообще не понял.
Также пользователи обычно не имеют прав админа, так что обновление возможно только в заранее оговоренный каталог. Да многое еще чего можно найти.
Это ограничение системы, а не установщика. MSI отлично может работать без админских прав.
А для тестов GUI было бы интересно узнать решение для винформс и контролов сторонних разработчиков.
Для винформс все вообще просто - у каждого контрола есть свой уникальный ID. Ищешь окно, берешь контрол - делаешь с ним что что хочешь.
Сложнее с WPF. Но и там есть AutomationID (если память мне не изменяет).
Это смотря какие цели ставить. Вот при нажатии на меню Открыть и на кнопку открыть будет открываться окошко? Это будет тоже самое окошко? А что будет если будет нажато Ок или Отменить?
Все это можно проверить и без GUI. Тут скорее вопрос о том, подумал ли кто-то о возможности тестирования на стадии разработки.
Просто для интереса, а что вы используете?
Мне нравится InnoSetup и в текущей конторе его тоже пользуют.
А в той где тестировали MSI решили пользовать NSIS
http://windowsreport.com/software-package-installer/
Вы просто не умеете его готовить
К сожалению, много времени прошло с тех пор, всех подробностей не помню. Но в любом случае инсталлер не должен создавать ситуаций когда дальнейшая работа с ним невозможна.
Вот это вообще не понял. - Кроме того сейчас можно достаточно просто вывести список всех локальных файлов, что вместе с ехе живут. А так прийдется извращаться.
сейчас, грубо говоря, делаем dir "*.exe,*.dll" и выводим доступную информацию о каждом файле. Номер версии, дата создания и пр.
Для ГАКа такой способ уже на канает
Для винформс все вообще просто - у каждого контрола есть свой уникальный ID
Уверены? Многие либы специально делаются так чтобы этих ИД было как можно меньше.
Помню давно давно делали редактор типа Визио, так если каждый элемент был окошком - это была просто катастрофа на более менее больших диаграммах.
Да даже если пользовать только стандартные всё что хочешь не сделаешь. На одном из проектов шеф только этим и занимался (поиском подходящей тулзы) - нифига не нашел. То бишь они конечно есть, но увы, обламывались именно там где было нужно.
Все это можно проверить и без GUI.
И каким образом? Кинуть команду контроллеру и проверить отклик во вьюве? Маловато будетъ....
Мне нравится InnoSetup и в текущей конторе его тоже пользуют.
И там решена проблема с reference counter?
Но в любом случае инсталлер не должен создавать ситуаций когда дальнейшая работа с ним невозможна.
Что значит не должен? Инсталлер - это инструмент, его можно использовать правильно и тогда все работает как надо, а можно косячить и тогда все работает кое-как. Это как фотоаппарат :) Шедевры же делает не камера ;) И на самую дорогую камеру можно снять говно :) Любым инструментом надо уметь пользоваться. А систему можно убить и с InnoSetup (у нас на прошлой работе, кстати, так и сделали :D)
сейчас, грубо говоря, делаем dir "*.exe,*.dll" и выводим доступную информацию о каждом файле. Номер версии, дата создания и пр.
Для ГАКа такой способ уже на канает
А зачем это может понадобиться? Нет, я понимаю, что вы инсталлируете хрензнает что методом простого копирования файлов из папки с флэшки сразу в продакшен... и там действительно хрен поймешь, что за горы файлов находятся в системе... Я даже больше чем уверен, что апдейт вы делаете путем простого перезаписывания старых файлов (собственно говоря InnoSetup только так и умеет, ну еще версию может проверить). А еще у вас наверняка периодически случаются даунгрейды (InnoSetup за это тоже любим)... Ясное дело, что через какое-то время система будет настолько засрана, что только руками можно будет разгрести.
Уверены? Многие либы специально делаются так чтобы этих ИД было как можно меньше.
Да, я уверен. ВинФормс работает на ID. Можешь почитать про WindowsProc. Просто используют одни и теже номера, но ИД должен быть уникальным на форме.
Помню давно давно делали редактор типа Визио, так если каждый элемент был окошком - это была просто катастрофа на более менее больших диаграммах.
Ну во-первых, в данном случае речь о простых контролах. Зачем ты приплетаешь сюда графические редакторы?
Во-вторых, даже если рисовать все без окон, все равно надо делать систему чтобы искать фикуры... так что можно использовать этот механизм и для тестов.
Да даже если пользовать только стандартные всё что хочешь не сделаешь. На одном из проектов шеф только этим и занимался (поиском подходящей тулзы) - нифига не нашел.
Я не знаю что твой шеф искал. Если код был ваш, то контролы можно искать перебирая AutomationID (понятно, что они должны быть уникальными). Тем более, если программу вы сами писали. Уж можно было сделать так, чтобы программа была тестируема ;)
И каким образом? Кинуть команду контроллеру и проверить отклик во вьюве? Маловато будетъ....
Зачем? Делаешь простой юнит-тест обработчика сообщения/эвента и все.
Мне казалось, что для этого придумали GAC...
-----
ГАК - вполне удобно хранит версии ДЛЛок. Проблему совместимости по загрузке он не решает.
А главной проге в манифесте просто указываешь с какими версиями плагина она умеет работать. Все :)
-----
Ну если бы все.
У него проблема, насколько Я понял, в том, что два разных плагина используют одну и туже общую ДЛЛку,
Пока версии плагинов линкованы с этой ДЛЛкой - все работает.
Потом ему надо заменить плагин и новая версия плагина использует другую версию общей ДЛЛки.
Соответственно, первый плагин загрузится без проблем используя нужную ему ДЛЛку,
а при загрузке второго произойдет конфликт - ДЛЛка загружена, но не той версии, а вторую загрузить
не получается из-за конфликта по именам.
Можно решить как указано выше - каждую версию в свой аппдомен.
Можно решить как указано выше - каждую версию в свой аппдомен.
При этом получаем interprocess communication между домейнами, тоже не подарочек. Особенно если скорость важна.
Но по другому никак не изолировать.
Сейчас правда новая задачка нарисовалась по ХМЛ сериализации объектов из разных либ. Сериалайзер вроде хочет XMLInclude в базовый клас, но ктож ему это даст. 
И там решена проблема с reference counter?
А у нас есть такая проблема? Ничего глобально не становится.
Инсталлер - это инструмент, его можно использовать правильно и тогда все работает как надо, а можно косячить и тогда все работает кое-как.
Визуал студио тоже вроде инструмент и всегда почти одинаково пользуется. Но с выходом новой версии всегда возникают проблемы.
Вот понравилось бы если бы ворд не мог открыть файл где пользователь накосячил с форматированием?
А инсталлер еще чувствительнее, как бы в нём не косячили в пределах разумного, он не должен вставать на рога и не выполнять своей основной функции.
А убить систему можно просто, у нашего тестера была фирменная плюшка - установить прогу на С:\Windows, А после деинсталлировать. Проверять только на виртуалке
А зачем это может понадобиться?
хотя бы чтобы найти нужный тэг в репозитории, либо глянуть историю изменений.
Есть большие отличия когда на фирме один два чисто софтовых проекта и когда софт идет вместе с железом по индивидуальному заказу.
Я даже больше чем уверен, что апдейт вы делаете путем простого перезаписывания старых файлов
А другой возможности просто нет. Инсталлер запускается один раз на чистую машину, когда приходит админ. Не пробовали на ХП сейчас что инсталлировать?
А что инсталлер не умеет, умеет Паскаль 
Да, я уверен. ВинФормс работает на ID. Можешь почитать про WindowsProc.
А вот вопросик, на форме есть 10 полей для ввода текста и 10 лейблочек к ним. Сколько может быть ИД? Сразу скажу что 20 совсем не обязательно.
Ну во-первых, в данном случае речь о простых контролах. Зачем ты приплетаешь сюда графические редакторы?
Так сразу сказал, что речь не идет о микрософтовских контролах. А в других принцип подобный.
систему чтобы искать фикуры
А енто что?
Уж можно было сделать так, чтобы программа была тестируема
вот у нас были все такие глупые, что до этого никак не додумались
Делаешь простой юнит-тест обработчика сообщения/эвента и все.
А примерчик мона? Что никак не доходит.
А у нас есть такая проблема? Ничего глобально не становится.
Ну т.е. если у вас есть плагин1, который использует компонентуА и плагин2, который использует туже самую компоненту, то компонентаА 2 раза устанавливается на систему - в каталог с плагином1 и в каталог с плагином2. И потом ты удивляешься, что у тебя пытаются загрузиться типы с одинаковыми названиями, но с разными версиями? :) Как говорится, сами себе злобные Буратины :)
Но с выходом новой версии всегда возникают проблемы.
Да ладно? Я что-то не припомню проблем при переходе со сторой VS на новую...
А инсталлер еще чувствительнее, как бы в нём не косячили в пределах разумного, он не должен вставать на рога и не выполнять своей основной функции.
Уверяю тебя, MSI работает предсказуемо. Более того, работа MSI очень хорошо описана в MSDN. Я не совсем понимаю, о каких "пределах разумного" ты говоришь... Фактически, MSI-файл - это база данных, в которой прописаны связи между новыми и уже установленными продуктами и файлами. Очевидно, что если нарушены какие-то связи, то что-то обязательно пойдет не так и тут нет и не может быть никакого механизма восстановления или исправления неправильных связей.
хотя бы чтобы найти нужный тэг в репозитории, либо глянуть историю изменений. Есть большие отличия когда на фирме один два чисто софтовых проекта и когда софт идет вместе с железом по индивидуальному заказу.
Тэг в репозитории? Вы там на коленке собираете? :) Нет, я уже понял, что вы не используете инсталлер. Хотя в данном случае есть еще один повод таки задуматься над инсталлером, т.к. в таком случае версиб продукта можно будет посмотреть в Add and Remove Programms, после чего можно будет легко выяснить какие именно файлы и каких версий входили в этот конкретный релиз. Единственный тэг в репозитории - это версия релизнутого продукта. И совершенно не важно с железом идет софт или нет, по индивидуальному заказу или нет. Есть релиз - есть уникальная версия продукта. Что может быть проще?
Не пробовали на ХП сейчас что инсталлировать?
Какая разница сейчас или не сейчас? На XP тоже есть MSI и работает он также, как на Win10 (еще года два тому назад мы поддерживали установку на XP и все работало на ура, так что я знаю о чем говорю :) ).
А что инсталлер не умеет, умеет Паскаль
Ну в MSI тоже есть Custom Actions, которые можно писать на VBScript или JScript ну или просто исполнять или dll.
А вот вопросик, на форме есть 10 полей для ввода текста и 10 лейблочек к ним. Сколько может быть ИД?
От 10 до 20. Лейблы могут быть без ИД, но в таком случае лейблы не генерят никаких сообщений и их нельзя ни задизейблить, ни покрасить... короче ничего с ними нельзя сделать.
А енто что?
очепятка :) "фигуры"
А примерчик мона? Что никак не доходит.
class MyCoolEventArgs : EventArgs
{
public bool FireException {get; set; }
}
someButton.Click += OnClick;
class SomeForm : Form
{
public void OnClick (object sender, EventArgs args)
{
MyCoolEventArgs myEvent = args as MyCoolEvent;
if (myEvent.FireException)
throw new MyCoolEventException ();
else
{
string fileName;
if (OpenForm (out fileName) == DialogResult.OK)
Save (fileName);
}
}
public virtual DialogResult Openform (out string fileName)
{
OpenFileDialog openFiledialog = new OpenFileDialog();
fileName = openFileDialog.FileName;
return openFileDialog.ShowDoalog ();
}
public virtual void Save (string fileName)
{
....
}
}
Теперь тесты:
Вот как-то так. Писал тут, так что ежели какие-то ошибки, то сори :) Но смысел, думаю, понятен.
Млять! Тесты потерлись :( Гребаный движок :( Лениво все восстанавливать. Если не понятно, как могут выглядеть тесты, то я восстанавлю, но надеюсь, что все понятно :D
Ну т.е. если у вас есть плагин1, который использует компонентуА и
ничего не так.
Во первых, описанная система со многими каталогами существует пока только в моей голове. Да и система с плагинами только на стадии зарождения. Как говорил, всё пишется в один каталог.
Во вторых, на систему с поддержкой многих версий времени не дают, так что пока остается идеей на поиграться дома.
И потом ты удивляешься
Я не удивляюсь, я ищу решение.
Да ладно? Я что-то не припомню проблем при переходе со сторой VS на новую...
Постоянно. Мурку спроси. Вот как сразу 2017 поставили, любила или вылетать или страшно тормозить. Не говоря уже о том, что все плагины нужно было было обновить.
Да и как какие то не стандартные операции делаешь, может не получится. Приходится просто перегружать студию. Жалко не записываю всё, а так что бы воспроизвести уже не помню.
то что-то обязательно пойдет не так
Можно согласится на то, что что то не установиться или станет неправильно. Но поставить систему на рога, чтобы вообще никуда - это уж слишком.
Не хочу ни чего доказывать, но очень не уверен, что было сделано что то неправильно.
тут нет и не может быть никакого механизма восстановления или исправления неправильных связей.
Ну да база у меня накернулась и усё механизма нету. Нужно систему заново переустанавливливать чтобы опять с базой работать.
т.к. в таком случае версиб продукта можно будет посмотреть в Add and Remove Programms
Ага, только пользователю еще нужно об этом рассказать и я что то не уверен что он вообще будет иметь туды доступ. Гораздо проще это сделать в диалоге "О программе".
Где кстати, будут именно те версии которые установлены на конкретном компе, а не те версии который должны быть по идее установлены.
которые можно писать на VBScript или JScript
А если тошнит и от того и от другого?
class SomeForm : Form
Это вообще в голове не укладывается. У нас выглядит примерно так
public void OnClick (object sender, EventArgs args)
{
_controller.DoActionSave();
}
public DialogResult IView.Save (string fileName)
{
....
}Но как говорил, задача стоит проверить самых верхний уровень, а не уровень презентера/контроллера
Как говорил, всё пишется в один каталог.
-----
Не клади плугины в каталог программы. Проверено - создает головную боль.
В твоем случае - в случае когда тебе надо иметь несколько версий - стоит класть каждый плугин в отдельную папку. Туда же - зависимые либы. Ну или хотя бы одна папка под каждую версию.
Не говоря уже о том, что все плагины нужно было было обновить.
-----
Ну это еще пустяки. Иногда непонятно что начинать крутить.
Я вот на 2017 еще не перехожу. Да, надо бы, но как подумаю что придется все перенастроить... лучше подожду 2020...
я что то не уверен что он вообще будет иметь туды доступ.
-----
У нас, для юзеров на машинах работающих со станками, вообще все что можно обрезано.
И все одно иногда умудряются что-то угробить... ну папочку там потрут из Саве-диалога...
Гораздо проще это сделать в диалоге "О программе".
-----
Когда Я это сделал первый раз - получил по шее - Я не стал парсить строку подключения к базе и показал ее целиком.
Поправил почти сразу. Потом, когда все усложнилось, туда прописались все детали по проге и плугинам Абоут стала первой страницей куда смотрят при возникновении проблем.
Это вообще в голове не укладывается.
-----
Ну это еще чего... Я как-то попробовал использовать Опен/Саве диалог... так, как рекомендовано мелкомягкими для расширения стандартной формы... Вот там был цирк с конями... что-то, однако, работало, а что-то так и не получилось сделать - проще было реализовать новую форму...
Уверяю тебя, MSI работает предсказуемо.
-----
Когда среда его работы идеальна - возможно.
Но приближенная к идеальной среда для МСИ - свежая винда в минимальной конфигурации.
В таком виде винда обычно не живет. Обычно идут наслоения с заменой каких-то компонентов.
Самый простой вариант проверки - использование инсталятора Студии - в 2015 невозможно
сказать - Поставь ВСЕ - инсталятор будет пыхтеть, но отвалится, оставив нерабочую Студию.
Так что - ой...
Не клади плугины в каталог программы.
А отчего думаешь задачка возникла?
Тут так, или всё в одной или в разных, с контролем версий. Работает и промежуточная стадия, когда все общие файлы в ехе, а то что к плагинам в отдельных, но это нормально работает, когда всего один проект. Раз настроил и забыл
"Всё в одной" - реализовать довольно просто, уж сколько раз делал, да и сейчас немного по другому сделал и работает.
А домейнами еще возится и возится, причём только дома.
Ну или хотя бы одна папка под каждую версию
Это вообще не канает. Сейчас всё грузится в один домейн.
Я вот на 2017 еще не перехожу...лучше подожду 2020
вот в 2020 как раз на 2017 и можно будет перейти
Мне проще, дали новый лапоть. Не совсем новый, от шефа, но и на том спасибо. Новые нам не подходят из за карточек расширения. Вместо того чтобы просто вставить карточку в лапоть, нужно таскать пару коробочек.
проще было реализовать новую форму
Это тоже нехорошо. Привыкают юзвери к системным диалогам. Я вот лично люблю файлики копировать из Save As диалога или "зип" запустить.
Хотя для диалога "выбора папок" приходится извращаться.
......
Я вот сейчас с ХМЛ сериализацией играюсь, стандартная вконец задолбала. Да и не нужно мне объекты восстанавливать, только их "содержание".
Тут так, или всё в одной или в разных
-----
У меня с моими, гораздо меньшими заморочками, и то возникает головная боль, когда оно в куче.
Чуток помогают атрибуты на классах, но сейчас появится порядка 100 + 20 плугинов под оборудование - надо будет что-то делать и скорее всего это что-то будет папкой с датой создания конфигурации оборудования.
Это вообще не канает. Сейчас всё грузится в один домейн.
------
Да ну? А какая связь между доменом куда все грузится и организацией размещения в файловой системе?
Это тоже нехорошо. Привыкают юзвери к системным диалогам.
-----
Это - нормально.
Мне нужен был диалог, используемый как стандартный диалог, но со своими прибамбахами, выходящими за рамки навигации/фильтрации.
Реализовать прибамбахи было относительно не сложно, но втиснуть их в стандартный диалог не получилось. Даже при том, что все доки и примеры имелись.
стандартная вконец задолбала.
-----
Хи-хи... Я уже давно забил... Что можно - стандартным, что нельзя - руками...
У меня с моими, гораздо меньшими заморочками, и то возникает головная боль, когда оно в куче.
У Мурки меньшие заморочки 
Не знаю, отчего у тебя головная боль, может воздух плохой в помещении.
У нас количество всего гораздо меньше, а копировать все в одно гораздо проще.
Потому как любая автоматизация требует соединения с сервером. А из китая, например, это не так просто сделать.
А какая связь между доменом куда все грузится и организацией размещения в файловой системе?
Это типо "суслика". Не видишь а он есть.
Сможешь загрузить в один домейн две разные версии подписанной ДЛЛ-ки? У меня не получается.
Хи-хи... Я уже давно забил... Что можно - стандартным
Чтобы забить на "стандарт", нужно вначале иметь свой.
Пока вот так сделал. "1" - версия
StorageData storageDataItem = new StorageData(123, "namexxx", 12345678);
using (XmlSerializerStorage storage = new XmlSerializerStorage("test.xml", 1, "Comment:Ser test"))
{
storageDataItem.Addition = "A1";
//storageData.Write(storage);
storage.Write(storageDataItem, XmlSerializerStorage.ESerilizationType.AllFields);
storageDataItem.Name = "test2";
storageDataItem.Addition = "A2";
storageDataItem.Write(storage);
storageDataItem.Name = "test3";
storageDataItem.Addition = "A3";
storageDataItem.Write(storage);
}
using (XmlSerializerStorage storage = new XmlSerializerStorage("test.xml", 1))
{
storageDataItem.Read(storage);
storageDataItem.Read(storage);
storageDataItem.Read(storage);
}
У меня не получается.
-----
Ну так оно и правильно.
Блин, "надо покласть две разные, но одинаково поименованные ДЛЛки в одну папку" и не поиметь при этом ни гемороя, ни головной боли.
а копировать все в одно гораздо проще.
-----
Ну зип/рар - какая разница - оба распакуют заданную структуру.
Встроить распаковщик - уже лет 5 как без проблем.
в один домейн
-----
Вроде уже рассмотрели и пришли к заключению - доменов будет несколько.
Осталось решить сколько, какие и как разгрести либы по доменам.
Хочешь грести из одного каталога и еще копировать руками - ну делай себе геморой.
Я же их разношу по максимуму, чтобы из пути было понятно что используется.
Пока вот так сделал.
-----
В каждом классе - либо метод, либо фриенд-метод.
Что-то большое и продуманное писать уже лениво... лет 10-ть назад - можно было бы... а сейчас - лениво...
-----
На сейчас мне вот что интересно - как оформить хост для компиляции и выполнения шаблонов, так чтобы при внешней загрузке шаблонов их выполнение было безопасным для системы в многопользовательском режиме...
Как-то так...
Пока не представляю где коvырять...
две разные, но одинаково поименованные ДЛЛки в одну папку" и не поиметь при этом ни гемороя, ни головной боли.
Не ну если спрашивает что такой файл уже существует и заменяешь все равно конечно будет головнаяа боль. Да и мв говорим видимо о разных временных интервалах.
Я лично о времени полной перекомпиляции проекта.
Встроить распаковщик - уже лет 5 как без проблем.
А при чём здесь зип, врое ничего не говорили о нём.
Вроде уже рассмотрели и пришли к заключению - доменов будет несколько.
Это только мы с тобой так решили, а шеф грит - нефиг тратить время.
Осталось решить сколько, какие и как разгрести либы по доменам.
А что там решать, каталог каждого плагина в папочку, папочку в домейн.
В каждом классе - либо метод,
Ну так и есть, может быть даже вообще ничего. Что тебе не понравилось?
как оформить хост для компиляции и выполнения шаблонов
Как виртуалка не канает?
Не ну если спрашивает что такой файл уже существует и заменяешь
-----
Ну так именно этот геморой ты и хочешь поиметь.
Тебе предлагается покласть каждую фиговинку покласть в папку и рулить загрузкой как тебе надо.
Ну а ты упираешься и отвечаешь - я буду разбираться со скинутым в одну папку...
Я лично о времени полной перекомпиляции проекта.
-----
Или это где-то сбоку, или Я потерялся.
А при чём здесь зип, врое ничего не говорили о нём.
-----
Один файл и распаковка структуры каталогов как задано при упаковке.
Вроде как нормально для того что тебе надо.
а шеф грит
-----
Ты таки хочешь, чтобы Я удаленно убедил твоего шефа?
Ты мои софтовые скилсы учитываешь?
папочку в домейн
------
Там не так все легко... Я пару раз ковырял аппдомены - для меня там мало интересного было.
Что тебе не понравилось?
-----
Ручная работа. Даже при том что Я много генерирую.
Как виртуалка не канает?
-----
У меня в этом плане параноя - считается, что целью загрузки шаблонов будет роняние системы. Вот целенаправленные действия и надо предотвратить. И не забыть выполнить работу...
Ну так именно этот геморой ты и хочешь поиметь.
не вижу проблемы, rebuild all & copy
Тебе предлагается покласть каждую фиговинку покласть в папку и рулить загрузкой как тебе надо.
Это две совершенно разные проблемы
или Я потерялся.
Мы видимо о разных вещах думаем.
Я размышляю о времени когда папка ехешника только создается.
Один файл и распаковка структуры каталогов как задано при упаковке.
так до времени упаковки я еще и не дошел - это и есть "инсталлер". Нужно для начала сделать рабочую версию.
Ты таки хочешь, чтобы Я удаленно убедил твоего шефа?
Я тебя просто информирую что иметь разные версии шефу не требуется. И не надо его переубеждать, даже удалённо. 
Там не так все легко...
Ну так IPC требуется когда домейны нужно подружить.
считается, что целью загрузки шаблонов будет роняние системы. Вот целенаправленные действия и надо предотвратить.
не дошло...
Ручная работа. Даже при том что Я много генерирую.
А где ты видишь ручную работу? Для ПОКО ка раз то что нужно, а для чего сложного как раз ручная работа и требуется
storage.Write(storageDataItem, XmlSerializerStorage.ESerilizationType.AllFields);
rebuild all & copy
Я размышляю о времени когда папка ехешника только создается.
------
Изначальная постановка задачи - загрузить нужную версию как апгрейд для существующей системы.
Если задача была изменена - Я не заметил.
не дошло...
-----
Надо защитится от
StartProcess("Format C: /Y")
Если задача была изменена - Я не заметил.
Задача осталась, обсуждение изменилось.
Кстати нашел еще пару вариантов: ILMerge
https://stackoverflow.com/questions/2460542/using-differen...
Extern alias
https://blogs.msdn.microsoft.com/ansonh/2006/09/27/extern-...
Хотя "свой локальный GAC" был бы видимо лучшим вариантом.
Надо защитится от StartProcess("Format C: /Y")
где? Просто на винде, первое что приходит в голову - UAC, привилегии...
ИЛмерге вот еще не пробовал - делать то почти ничего не надо
-----
Это линковщик - либо ты руками прописал что тебе надо и он собрал, либо снова на поле 1.
Вопрос об загрузке плугина вообще не стоит.
Второй линк заканчивается вот этим:
static void Main(string[] args){FooVersion1::Acme.Foo f1 = new FooVersion1::Acme.Foo();f1.Bar();FooVersion2::Acme.Foo f2 = new FooVersion2::Acme.Foo();f2.Goo();}
Тебе же нужно чтобы Фоо бралось из сменной библиотеки после линковки.
работы дофига.
-----
Хи-хи...
Это линковщик - либо ты руками прописал что тебе надо и он собрал
Там тоже проблем может быть
http://www.bjoernrochel.de/2009/07/07/how-to-shoot-yoursel...
не хочется все на себе пробовать....
Второй линк заканчивается вот этим
главное идея - можно враппер зафигачить динамический или еще что. Пока даже и не думал.
Вот знаешь на каком принципе ГАК работает? Я в эту сторону тоже не рыл.
работы дофига.
-----Хи-хи...
ну не для себя же делаю. Пока требуется проще, но быстрее.
можно враппер зафигачить динамический
-----
Статический. Статическая предлинковка. А у тебя - динамическая загрузка.
Т,е, либо ты заранее знаешь все используемые дллки, либо ловить нечего...
Вот знаешь на каком принципе ГАК работает?
-----
Имеет структуру каталогов в соответствии типами и версиями и хранит копии всех версий дллок.
Глубже не копал.
Пока требуется проще
-----
угу...
Пока требуется проще
-----
Днями полностью запутался (у меня чуток сложнее - плугины должны суммировать кое-какие данные при начальной загрузке... из других плугинов) в имплементации и загрузке плугинов. Чтобы прояснить кто кого и как загружает слепил небольшой проектик с чистыми плугинами, работающими с одним и тем же БО. Базовые классы не даю - можешь заменить чем нужно.
Манеджер плугинов - выделен, можно подстроить под любые нужды.
Прикреплённые файлы
Спасибо конечно за исходники, но "простой вариант" у меня есть достаточно давно.
Причем твой не должен работать когда общие либы в одном месте, а либы плагина в другом.
Нашел другую проблему. А именно лицензия на использование ILMerge.ехе
Здесь пишут что коммерческое использование низзя
https://www.codeproject.com/Articles/17797/Gilma-GUI-for-t...
Туть на одной странице подтверждение, а на другой что это опен соурсе проект
https://www.microsoft.com/en-us/research/people/mbarnett/?...
https://github.com/Microsoft/ILMerge/blob/master/LICENSE
и коммерческое использование можно
еще вот пару ссылок нашел
https://www.codeproject.com/Articles/4352/Demystifying-the...
http://www.telerik.com/blogs/working-with-assemblies-in-th...
Хи-хи... работает, однако...
Млм я чего не заметил или делаешь по другому.
Пример:
Результаты бильда
*Кат пл1*
пл1.длл
соммон.длл
а1.длл
*Кат пл2*
пл2.длл
соммон.длл
а2.длл
*Кат ехе*
апп.ехе
соммон.длл
б1.длл
---
Что у пользователя
*Кат пл1*
пл1.длл
а1.длл
*Кат пл2*
пл2.длл
а2.длл
*Кат ехе*
апп.ехе
соммон.длл
б1.длл
На использование она у тебя со Студией.
И где она у тебя в 2015 сидит? у меня нет.
И проект не компилируется
Млм я чего не заметил или делаешь по другому.
-----
Делаю - обычно.
Бизнес-объекты лежат в папке с программой.
Плугины лежат в другой папке.
Связка определяется как папочка в проекте куда помещаются линки на дллки плугинов и "копи иф нювер". Она же указывается как место хранения в загрузчике.
Могу скинуть полный проект - подебажишь.
Вроде все.
И где она у тебя в 2015 сидит? у меня нет.
-----
Посмотрел - действительно - отдельной тулузы в Студии не нашлось.
Вроде была со Студией 2005, но это было давно, не помню.
Зато она точно идет с Рхино.Моск с гитхаба. Лицензию не смотрел.
Еще вот интересное нашел - Fody.Costura. Может кому понадобится
http://www.manuelmeyer.net/2016/01/net-power-tip-10-mergin...
/********************/ /** ЗАДАЧКА **/ /********************/
Вот еще задачка появилась.
Есть прога (и не одна), новые клиенты постоянно хотят что то индивидуальное для себя иметь. То поле для ввода добавить, то убрать, то все поля из базы читать, то из сервера получать. То вообще всей прогой удалено управлять, так как прога соединена с устройством и нужно не только локальное управление им и получение данных, но и удаленное. Вариантов разных просто дофига может быть со временем.
Требуется иметь Одну (базовую) версию проги с какими-то клиентскими вариантами отдельно.
Варианты решений тоже давно существуют, но хочется найти наиболее удобный.
Что можете предложить?
Требуется иметь Одну (базовую) версию проги с какими-то клиентскими вариантами отдельно.
Варианты решений тоже давно существуют, но хочется найти наиболее удобный.
По опыту оптимально иметь "прокладку", в которой реализованы все возможные запросы к серверам и базам данных. Работа "прокладки" с клиентами ведется по TCP (нужно еще универсальный и легко расширяемый протокол к нему сваять), неважно, локально клиент исполняется, или удаленно. При добавлении новой базы данных интерфейс работы с ней реализуется только в "прокладке", ну и трансляция запросов туда-сюда в/из своего протокола добавляется. Клиентских версий на такую архитектуру можно вешать немеряно, "базовая версия проги" - это реализация клиента для сервера-"прокладки" с поддержкой протокола обмена данными, ну и GUI там базовый ко всему этому.
"базовая версия проги" - это реализация клиента для сервера-"прокладки"
Как я понял предлагется сделать 5 слоев: ядро приложения, абстрактный слой коммуникации, конкретный слой коммуникации к которому подключен ГУЙ и слой удаленного доступа.
Как быть с вариантом, когда нужно добавить пару полей к вводу данных? Они должны просто добавляться к измерению и попадать в отчёт. Всё остальное без изменений.
Работа "прокладки" с клиентами ведется по TCP
А вот это уже не обязательно. Клиент сам устанавливает протокол подключения.
нужно еще универсальный и легко расширяемый протокол к нему сваять
Слой коммуникации остался еще с тех времен когда нужно было устройство подключать или по СОМ порту или по блутусу или еще как.
Как я понял предлагется сделать 5 слоев...
Ну да, типа того, самое главное с самого начала правильную и достаточно гибкую архитектуру заложить, вначале немного геморройно все это вместе связывать, зато впоследствии достаточно легко расширяемая система получается.
Как быть с вариантом, когда нужно добавить пару полей к вводу данных? Они должны просто добавляться к измерению и попадать в отчёт.
Не понимаю суть проблемы. Если эта пара полей модифицирует запрос, то "прокладка" должна уметь это обрабатывать, если нет, то это проблема обвески базовой версии клиента, #ifdef в помощь :))
А вот это уже не обязательно. Клиент сам устанавливает протокол подключения.
TCP (ну или named pipe) - это как пример соединения, при котором похрен, локально ли запускается клиент, или удаленно... А так можно реализовать что угодно, у меня, например, некоторые интерфейсы по shared memory данные получают, иначе пропускной способности каналов не хватает :))
самое главное с самого начала правильную и достаточно гибкую архитектуру заложить
Еще проблема в том что есть достаточно старых прог, которые нужно адаптировать. Хотя смысл обсуждения как раз то и в нахождении приличной архитектуры. Не слишком много но и не слишком мало.
И многие части должны быть общими (библиотечными).
Не понимаю суть проблемы.
В Вашем предложении GUI есть отдельный слой. Что в принципе вырождается в начальную проблему только не относительно приложения, а относительно GUI.
Ну типа есть пяток окошек и пару из них нужно слегда модифицировать. Копировать всё не вариант, изменения в "базовой версии" "проецируемые напрямую" в новую должны появлятся автоматом.
это как пример соединения, при котором похрен, локально ли запускается клиент, или удаленно
То есть "внутри" и "снаружи" могут быть разные типы соединений? Еще один слой?
А что shared memory можно пользовать удалённо?
А что shared memory можно пользовать удалённо?
Нет конечно. Просто когда запрашивается удаленный доступ к высокопроизводительной системе, то приходится дополнительно отделять только GUI, и связывать его по TCP с основной системой, в которой есть еще разделение компонент в пределах одного сервера, там и пользуется иногда shared memory для связывания. Но один хрен в итоге удаленный доступ GUI практически не используется, все исполняется на одном сервере (TCP связывание GUI осталось, изврат конечно, но не переделывать же), а удаленный доступ к серверу реализуется через Radmin/Dameware/mstsc-rdp.
Копировать всё не вариант, изменения в "базовой версии" "проецируемые напрямую" в новую должны появлятся автоматом.
Можно сделать, например, так, чтобы часть GUI/клиентской программы (тип и расположение полей, а также связанные с ними действия, и т.д.) считывались сначала с конфигурационного файла (для упрощения разработки), а не жестко кодировались, и GUI формировался on-the-fly. Затем вместо файла передавать эти конфигурационные данные с сервера сразу после подключения клиента. Тогда и получится
изменения в "базовой версии" "проецируемые напрямую" в новую должны появлятся автоматом.
считывались сначала с конфигурационного файла (для упрощения разработки), а не жестко кодировались, и GUI формировался on-the-fly.
Вместо дизайнера всё писать ручками и изобретать свой хамл для винформс, а для впф хамл на кусочки делить?
А данные как паралельно менять?
Есть у нас одна система "on-the-fly". Слышал только матюки когда её пользовали. Есть и другая система которая меняет свою работу в зависимости от файлов конфигурации - так только один человек знает как их правильно менять (разработчик).
А они лучше TeamViewer?
Понятия не имею, что есть, то и пользуем. Для mstsc-RDP не надо ставить графическую карту на сервер, но если надо несколько view получить, то RDS-Shadow mode - полная задница. Раньше Dameware пользовали, несколько лет назад IT на Radmin перешел, чем он лучше/хуже чем TeamViewer - х.з., но Radmin вроде намного быстрее и качество картинки у него выше, чем у TeamViever, но лично я TeamViever не пользовал, сравнить ощущения не могу...
Вместо дизайнера всё писать ручками и изобретать свой хамл для винформс, а для впф хамл на кусочки делить?
Ну я же не знаю специфики ваших задач, но на плюсах с GUI на winapi нерешаемых проблем не вижу.
Есть у нас одна система "on-the-fly". Слышал только матюки когда её пользовали.
Идеальных систем нет, если удается нормально реализовать что-нибудь, то появляются ништяки, а иначе - мат, страдания, ну и творческий поиск... :))
...так только один человек знает как их правильно менять (разработчик).
Нормально, это лучший Kündigungsschutz, так сказать. :))
нахрена GUI руками описывать
Так сложилась жизнь. (с) Управляющие GUI не слишком сложные, бОльшая часть софта используется in-house, а шефу все время хочется ну ооочень нестандартного поведения от "стандартных" элементов GUI. Но я, в общем-то, и не жалуюсь. :))
Бросается в глаза, что проблемы в разговоре нет ВООБЩЕ, т.е.
"а как бы вот взять и сделать нечто эдакое, а?"
"да нет проблем, и не такое решали: вешаешь гуи по тисипи и всех делов"
...
Таких "нормальных разговоров" можно вести сотню одновременно. Так это вальяжно. Но когда проблема стоит реальная, а не витает над кружкой с пывом, то решение очень редко находится в таких разговорах. Над серьезными настоящими проблемами нужно думать. А для этого требуется время, попытки, анализ и пр. А здесь такое впечатление, что человек сделал глоточек из кружки, прочел пост, ответил быстренько, и только после этого сделал следующий голоток из кружки. Крутые парни ... А Ваш собеседник наверняка майкрософт крышует, или еще какоого-нибудь оракэла (кстати, я - его знакомый :
).
решение очень редко находится в таких разговорах
-----
Ты не прав.
Треп дает пищу для размышлений. Если не рассчитывать на то что дадут готовое решение, а прорабатывать варианты - треп аккурат годится.
Есть еще моментик. У меня 4 больших части - система импорта, планирование, производство и отчеты. По хорошему надо бы человека 3-4 на каждую часть. В наличии - один на все. Треп, в моем случае, позволяет работать еще и по своим интересам.
Но когда проблема стоит реальная, а не витает над кружкой с пывом, то решение очень редко находится в таких разговорах.
Вы видимо проецируете это на себя. Проблема довольно реальная и она решается, общение на форуме предполагает поиск альтернативных решений и новых ассоциаций.
Иногда даже просто описание проблемы помогает найти решение. У вас не было такого что решение проблемы находилось в курилке, за обсуждением казалось бы вообще посторонних вещей.
У меня есть большое подозрение, что наше общение было сильно абстрактным и это вам пришлось не по душе.
Вот первая часть вам может показаться тоже совершенно бессмысленной, а мне лично помогло больше понять проблему.
что проблемы в разговоре нет ВООБЩЕ
Если хотите, могу пересказать пост с проблемой, там я специально "блоковые" комменты добавил чтобы немного в глаза бросалось.
И проблема не в том как с помощью языка Х реализовать алгоритм У, а в нахождении удобной архитектуры приложения для конкретного случая.
Похоже одну проблему решил. Как стандартное приложение пилить под запросы клиентов.
В итоге оказалось довольно просто для приложений типа "баальшой диалог" (без МДИ). Пока пробую винформс, но WPF похоже должен работать то такому же принципу.
Главное требование к приложению - должно быть написано с использованием Model-View-Presenter. Если всё крутится в коде формы, то переписать. Главное иметь интерфейс для главного вьюва.
После делим элементы интерфейса на связанные группы (или пользует отдельно каждый контрол) и помещаем эти группы в юсер контролы.
Теперь просто заменяем старую имплементацию вьюва (class MainForm: Form, IMainView) на новую (class MainForm: IMainView) где прямое использование контролов меняется на контролы из новых груп.
Вызов и загрузка приложения также переписывается через интерфесы, но тут особых проблем нет. Обмен данными также через интерфейсы и команды. Главное - на "линии разреза" только интерфейсы.
Теперь хост приложение делает какую требуется форму и в местах расположения "стандартных" контролов располагаем обычные панельки в которые и вставляются юсерконтролы из "стандартного приложения".
Если кому это понадобится могу подробнее расказать.