Иван Корюков, таких задач нет, контора не большая, никакого масштабирования не нужно будет точно. Поэтому, видимо, это самый простой для меня вариант будет, тупо поставить рядом его и всё. Спасибо за ответ, принимаю как верный :)
Или всё же проще поставить нужные SDK для сборки на сам сервер, рядом поставить и докер, и jenkins? Задач глобальных никаких, контора небольшая всё равно. Хороший ли это кейс будет?
Drottarutarnum, "Я уделил всего день его изучению", но уже не нравится и там всё не так. Как клиенты узнают друг о друге? Первый раз слышу. Signalr это средство, а не решение, как сделаете - так и будет работать, сделаете - будут знать друг о друге, не сделаете - не будут. "Хаб и все-все-все" - это как? Смысл не понял. Конечные точки в хабе лишь средство, а не решение :)
Gedonist, в любом случае у SignalR есть таймауты, пробовали их настроить? Когда работал с сигналом, то никаких проблем не было с отключением клиентов, ни разу
Сразу пару замечаний:
1) статика - зло, уберите статичный лист с пользователями, это bad practice
2) Используйте типизированный хаб, чтобы не делать Clients.All.SendAsync("UsersListChanged")
Вы уверены, что метод OnDisconnectedAsync не вызывается? Может просто ничего из листа не удаляется?
Василий Банников, ну, по сути щас так и есть, в 1 репозитории лежит 2 апи разных, библиотеки там же, но в других папках, то есть: api1: d:/repo/api1, api2: d:/repo/api2, dll1: d:/repo/dll1, dll2: d:/repo/dll2. api1 & api2 ссылаются на обе dll, то контекст мне надо указывать на d:/repo? как он поймет тогда, что мне именно надо собрать api1, а не api2? в будущем в репозитории будет много api, например, как быть?
Василий Банников, если правильно понял, то монорепозиторий - когда все проекты в 1 репозитории? Если да, то как это поможет? Проекты всё равно по разным папкам лежат же
Василий Банников, уже думает над тем, чтобы собирать на dev компах, публиковать в нужную папку, откуда докер и будет всё тащить, таким образом уже всё нужное будет в 1 месте (в т.ч. нужные dll). Но не знаю, есть ли уже после этого смысл
+1 к тому, что 20-30 проектов - норма, текущий проект на работе буквально сейчас состоит из 26 проектов, но у меня там всего 3 exe, а остальное - dll.
Каждая dll должна отвечать за свое, например у нас это: 1 - общие классы для ответов от API (несколько API отдают одинаковые ответы (по формату т.е.)), exception и прочие штуки, 2- библиотека для авторизации через JWT, общие настройки JWT, пр., 3 - Unit of Work (который сам состоит из 3 проектов) и так далее. Сделано это для того, что бы не тащить ненужное в проекты, нужен сервис генерации рандомной строк (как пример) - добавил 2 библиотеки (в нашем случае 2, потому что есть интерфейс и его реализация в другой библиотеке) и используешь его везде.
Поэтому ваши 20-30 проектов, если сделаны грамотно, то никаких сложностей не доставят, наоборот повышают (ИМХО) гибкость ваших проектов.
Docker контейнер 50\50 для меня, мне нужно будет еще и контейнеры запускать, а делать dind не хочется от слова совсем