Задачки на подумать
Хи-хи... работает, однако...
Млм я чего не заметил или делаешь по другому.
Пример:
Результаты бильда
*Кат пл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. Но я, в общем-то, и не жалуюсь. :))
Бедненькие.
