Переформулировать не хочешь?

ну завтра опять не на работу можно и подлинее написать. В одно предложение не получится, да и проблема достаточно обширная. Я и так ее сократил по минимуму.

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 в дополнение

Путь боли :)

OSGi тоже не так проста в понимании, но 7 компонентов в ней слава богу нет.

А может что-то может оставаться пустым?

OSGi тоже не так проста в понимании

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

Здравствуйте.

Не нашел другого места, где попросить помощи. Извините, что влез к вам. Но название темы как нельзя к моему вопросу.

Хочу попробовать сделать дома миниАТС с выходом на стационарную линию, но вместо ДЕКТ трубок использовать сотовые телефоны членов семьи. Это можно сделать программными приложениями (допустим Роутер с 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)
{
....
}

Но как говорил, задача стоит проверить самых верхний уровень, а не уровень презентера/контроллера