Вопрос вообще не так составлен. Во первых отношения к ASP.NET он отношения не имеет, а сложность явно не "сложно". Минута духоты кончилась, теперь по самому вопросу: руками эти данные править нельзя, используйте IPasswordHasher, который генерирует хэши паролей.
Евгений Механиков, я не DevOps, просто нужно как-то наладить систему билдов и тестов, чтобы не ручками, поэтому выбор пал на Jenkins, k8s я, если начну изучать, то головой точно поеду, надеюсь, что можно как-то проще решить
Иван Корюков, таких задач нет, контора не большая, никакого масштабирования не нужно будет точно. Поэтому, видимо, это самый простой для меня вариант будет, тупо поставить рядом его и всё. Спасибо за ответ, принимаю как верный :)
Или всё же проще поставить нужные 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 репозитории? Если да, то как это поможет? Проекты всё равно по разным папкам лежат же