Мой опыт использования миграций EF и EFCore показывает что применение миграций к БД непосредственно из основного приложения рано или поздно приведёт к проявлению граблей. Имеет смысл написать отдельную утилиту для менеджмента БД. И в ней уже проводить миграции, чистку, заполнение исходными данными. А основное приложение должно "падать" в случае проблем с БД.

Если уж решение требует использования миграций в основном приложении, то, опять же, опыт показывает, что EFCore в процессе создания новой миграции должна использовать свои стандартные механизмы для формирования объекта контекста БД по средствам либо:

• метода CreateHostBuilder в классе точки входа;
• реализации интерфейса IDesignTimeDbContextFactory.
  

Файл конфигурации захватывается системой только при первом запуске, или можно в последствии можно так переконфигурировать систему через добавление/редактирование этого файла на флешке?

И ещё вопрос: как можно несколько сетей добавить в конфигурацию? Просто добавив блоки

network={
ssid="Your network name/SSID"
psk="Your WPA/WPA2 security key"
key_mgmt=WPA-PSK
}

Большое Вам спасибо за статью! Она именно то, что нужно для решения нашей проблемы динамического конфигурирования интерфейса!

Ещё одна причина была изобретения велосипеда: помимо процесса разбора строки и компиляции результатов в нативный код в промежуточных этапах надо всё-таки получить кое-какой контроль над самим объектом мат.выражения: его модификации, простейшие (и не очень) операции с другими мат.выражениями, замена, подстановка переменных, добавление специальных переменных, значения которых были бы вычислимы при каждом вычислении мат.выражения, либо генерировали события, обработчик которого определял бы их значения. Слишком сложные были критерии, что бы заняться адаптацией существующих решений.

Пардон! Я имел в виду dynamic в реализации платформы.
Что касается производительности, то это действительно предмет отдельного исследования. Вопрос тут скорее сводиться будет к анализу объёмов генерируемого IL-кода.

У нас лет 7 назад был проект реализации пилотажных приборов для отладочных целей на борту. Там был очень медленный индустриальный комп с очень малыми объёмами пространства вообще подо всё. Кроме того, в ряде случаев встают вопросы сертификации кода по разным критериям. И доказывать, что здесь необходима дополнительная сборка бывает достаточно увлекательно.

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

Благодарю. Если будет дан дальнейших ход разработки парсера (видимо уже третья версия), то Ваш опыт не будет лишним.

С TeX'овской разметкой сейчас отдельное направление разработки. Если подскажете готовый работающий код разбора и рендринга, буду премного благодарен!

По коду — ссылка в статье ведёт в пространство имён самого парсера. Остальная часть проекта — это в основном всё, что так, или иначе пришлось самостоятельно реализовывать по причинам невозможности использования сторонних библиотек, либо по причинам хобби. Так что код в целом всего проекта ни разу не претендует на завершённость. И мало вероятно когда-то таким будет.
Что касается использования сторонних пакетов, то не всегда есть такая возможность, не всегда есть именно то, что нужно, либо не всегда есть только то, что нужно.
Ну и да — опечатки, ошибки…

Безусловно текстовый парсер строго академически должен работать на основе унифицированного лексера и описания правил лексики. Но беда в том, что во-первых, нужен готовый работающий код, во-вторых, нужен подконтрольный код, в-третьих, нужно минимизировать использование сторонних библиотек (вообще желателен единый исполнительный файл, да ещё и минимального размера).
А вот за ссылку отдельное спасибо!

System.Linq.Dynamic проигрывает в производительности прямой компиляции кода накладными расходами на кэширование. И при достаточно больших объёмах вычислительных задач этот проигрыш будет заметен. Но тем не менее это один из возможны вариантов решения. В ряде случаев он будет даже удобнее. Но опять же, нужен либо готовый работающий из коробки код, либо время на реализацию.

Я видел Вашу статью как раз в момент обзора вариантов решения моей задачи. Проблема в моём случае заключается в том, что парсер является лишь малой частью того, над чем приходится работать. Он был призван упростить решения ряда задач. И когда стоял выбор — реализация его на основе механизма грамматик, или влоб — задача свелась либо к реализации конкретно парсера, либо к реализации целого механизма грамматического разора. Первый путь показался на тот момент прямее и проще. Для меня…
В статье освещена, по сути, вторая версия. И как только она себя изживёт, либо докажет ограниченность своей реализации. либо как появится время освоить теорию по грамматическим конструкциям, то безусловно код будет переписан.