— Как мейнтейнеры библиотек находят свободное время для их поддержки, не занятое продуктовыми задачами?
— При выпуске новой версии библиотеки каким образом она попадает в места использования старой версии?
— Как пользователи, желающие использовать компонент интерфейса, могут узнать, что он уже реализован?
— При доработке готового компонента интерфейса как контролируется, что не будут сломаны места, где он используется?
Если нужны разные браузеры, то нужен Silenium. Если нужен один браузер, без зависимостей, который можно запустить в консоли, то Headless Chrome хорошо подойдет.
Я использовал свой мигратор потому, что в моем проекте система плагинов и у каждого плагина собственная структура БД, для которой отдельно ведется учет версий. EF migrations в рамках одной БД такого не умеют :(
А в какой студии вы пробовали превью .NET Core? В статье написано, что стабильная версия с ним работать не умеет и нужно ставить превью VS. Я сам не пробовал ставить (т.к. сижу на маке), но, возможно, превью VS будет нормально работать.
Пару лет назад я участвовал в разработке ecm7migrator (форк Migrator.NET, постепенно полностью переписанный). Он имеет простой API, не завязан на ORM и покрыт тестами. Использовал мигратор в нескольких проектах с NHibernate и очень доволен. В принципе, остальные, кому рекомендовал — тоже довольны.
Сейчас делаю большой проект на .NET Core. Там использую EF, т.к. особого выбора нет. Пробовал его миграции, но не подошли, т.к. неудобно писать руками + они не умеют вести параллельно несколько «линий» версионирования (в моем проекте нужно, чтобы плагины могли создавать себе нужную структуру БД и для каждого плагина отдельно велся учет версий).
В результате портировал на .NET Core ядро ecm7migrator и модуль, поддерживающий PostgreSQL. Всё завелось легко и тесты прошли без проблем.
Посмотрите его, возможно, вам покажется удобнее остального. Я готов оказать помочь в использовании и в портировании на .NET Core модулей для поддержки других СУБД.
Код на C# при переходе на .NET Core почти всегда нормально работает без изменений, но, если вы используете сторонние библиотеки, они могут не работать.
Как у вас реализовано взаимодействие с ethernet-шлюзом Noolite?
Взаимодействие со шлюзом — по HTTP через его API. Код, работающий со шлюзом — здесь.
Не задумывались на развертывании на более компактном железе? Типа Raspberry Pi?
Задумывались. Сейчас пишем новую версию на .NET Core. Она должна работать везде, где работает .NET Core. Насколько я знаю, в ближайшем будущем он будет работать и на Raspberry Pi тоже.
— Как мейнтейнеры библиотек находят свободное время для их поддержки, не занятое продуктовыми задачами?
— При выпуске новой версии библиотеки каким образом она попадает в места использования старой версии?
— Как пользователи, желающие использовать компонент интерфейса, могут узнать, что он уже реализован?
— При доработке готового компонента интерфейса как контролируется, что не будут сломаны места, где он используется?
nooLite API для .NET Core опубликован в NuGet
Странно, что обошли вниманием Headless Chrome.
Посмотрите mocha-headless-chrome, там нет Silenium от слова "совсем".
Еще можно развернуть postgresql в Docker контейнере.
Я использовал свой мигратор потому, что в моем проекте система плагинов и у каждого плагина собственная структура БД, для которой отдельно ведется учет версий. EF migrations в рамках одной БД такого не умеют :(
Там .NET API для MRTF1164, но оно ещё не готово.
Да, вы правы, у меня неточная формулировка.
Прошу прощения, я опечатался в статье. Нужно набрать "dotnet --info", а не "dotnet info". Исправлю.
И вот небольшое видео по теме https://events.yandex.ru/lib/talks/3875/
Сейчас делаю большой проект на .NET Core. Там использую EF, т.к. особого выбора нет. Пробовал его миграции, но не подошли, т.к. неудобно писать руками + они не умеют вести параллельно несколько «линий» версионирования (в моем проекте нужно, чтобы плагины могли создавать себе нужную структуру БД и для каждого плагина отдельно велся учет версий).
В результате портировал на .NET Core ядро ecm7migrator и модуль, поддерживающий PostgreSQL. Всё завелось легко и тесты прошли без проблем.
Посмотрите его, возможно, вам покажется удобнее остального. Я готов оказать помочь в использовании и в портировании на .NET Core модулей для поддержки других СУБД.
Код на C# при переходе на .NET Core почти всегда нормально работает без изменений, но, если вы используете сторонние библиотеки, они могут не работать.
Кстати, мы пробовали написать 1wire плагин. В результате решили его не включать в список стандартных, т.к. он требовал дополнительной установки сторонних библиотек. Но вы можете использовать его как пример кода: https://github.com/dima117/thinking-home/tree/1e198d3cff1abc0643020db8972f9cd6fdd91a66/ThinkingHome.Plugins.OneWire
Нужно браться за студию. Готов помочь в этом!
Взаимодействие со шлюзом — по HTTP через его API. Код, работающий со шлюзом — здесь.
Задумывались. Сейчас пишем новую версию на .NET Core. Она должна работать везде, где работает .NET Core. Насколько я знаю, в ближайшем будущем он будет работать и на Raspberry Pi тоже.