Станислав Макаров

После нажатия «Войти через браузер» должен открыться собственно браузер со страницей гитхаба, где вы должны нажать кнопочку «Разрешить».
Если вы не разрешили или что-то пошло не так, то только тогда вылезет предложение ввести пароль в терминале. Но там вместо пароля нужно вводить не ваш гитхабовский пароль, а текст токена, который вы должны были заранее создать. Токен вам покажут только один раз, поэтому скопируйте его в буфер и сохраните где-нибудь.
И вставляйте его в терминале тоже через буфер обмена, чтобы не ошибиться. При вводе паролей с терминале их никогда не видно, не пугайтесь и просто жмите Enter после ввода.

Есть опция PublishSingleFile - как раз склеит DLL и exe.

self-contained можно отключить

dotnet publish -c Release -r win-x64 -o ./pub -p:PublishSingleFile=true --self-contained false

Да, всё верно поняли. Дизайнер XAML не совсем "дружит" с кодом - он ищет только те, которые уже скомпилированы. Видимо, дизайнер ищет классы стандартным способом - через тип Type (и т.п.), а тот ищет среди сборок (exe/dll) проекта.

Нужно сразу скомпилировать новый тип, даже просто пустой class Test {} - и всё, будет работать. Лучше делать это пораньше - до того, как пытаетесь связать его в xaml, иначе билд не срабатывает, и приходится выпиливать его из xaml-а.

Реализуй вот это
Задача
Доработка сканера серийных номеров с этикеток.
Цель: доработать существующий сканер этикеток.
1. Система должна давать возможность нахождения и распознавания серийного номера независимо от иного текста, цвета фона, кол-ва символов S/N.
2.Скорость - не менее 1,5 сек на объект
3.Точность распознавания - не менее 96%
4. Динамический выбор области сканирования с помощью татч-скрина
5. Системные требования IOS, Android.

Это конечно перебор для вас в области 4,5
Но просто сделай на основе фото.
Как заготовку сможешь использовать это, баркоды пакеты
ZXing.Net
ZXing.Net.Bindings.CoreCompat.System.Drawing

Серийный номер Tesseract

https://github.com/vkorotenko/VueRecaptcha

Прокидывай секреты через переменные среды. Благо по умолчанию IConfiguration умеет работать со слоёными конфигами, где по порядку применяются следующие слои:
1. appsettings.json
2. appsettings.Environment.json
3. переменные среды
4. аргументы командной строки

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

Локально (на машине разработчика) переменные среды можно хранить в .env файлах, либо можно продолжать иметь дополнительные appsettings - это тоже ок.

При разворачивании образа, повторюсь, прокидывай секреты в переменные среды.

Так делают почти все, и все оркестраторы умеют с этим работать и прокидывать в переменные среды контейнера значения из каких-нибудь файлов или даже из хранилища секретов типа vault.

Push отправляет во внешний репозиторий origin ваши новые коммиты, которых там ещё нет. А указатель ветки origin/master просто передвинется на новую вершину цепочки коммитов (fast-forward). Никакого коммита слияния при этом не создаётся и конфликтам возникнуть в принципе неоткуда.
Кто с кем должен конфликтовать по вашему мнению?

Если тебе нужна библиотека классов, в которой есть только метод, который вычисляет площадь треугольника, то лучше сделать статический класс со статическим методом:

public static Triangle {
  public static double CalculateArea(double length0, double length1, double length2) {
    // Весь код по вычислению площади
  }
}

Функция Print тебе в библиотеке совершенно не нужна.

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

Первый способ популяризирует публичные универсальные инструменты разработки.
Второй способ эксплуатирует проприетарные инструменты.

Первый способ отдает разработку и поддержку движка на аутсорс непосредственно разработчикам инструмента, часто за отдельную плату, часто сопровождаясь или длительным ожиданием, или отсутствием гарантий внедрения требуемых решений.
Второй способ позволяет быть на короткой руке непосредственно с разработчиками инструмента, но требует от разработчиков экспертности знаний в требуемых для разработки областях. С одной стороны таких людей очень сложно найти, с другой стороны таким людям надо очень много платить.

DirectX, Vulkan и OpenGL, равно как Metal и ряд проприетарных GAPI некоторых закрытых платформ, не являются графическими библиотеками. Это все - Graphics Application Programming Interface - GAPI.
Это - низкоуровневые интерфейсы драйвера GPU, позволяющие эксплуатировать ресурсы видеокарты в своих целях. Не только для рисования чего-то, а для ИИ, ML, сложных статистических вычислений, предсказаний и прочих расчетов на больших объемах данных.
Под капотом любого инструмента, будь-то проприетарный или публичный, в его графическом слое используется один или несколько GAPI. Без этого никак.
OpenGL, как и DirectX 11, нисколько не устарели, поскольку предоставляют упрощенный интерфейс управления ресурсами GPU. Они используются тогда, когда разработчикам не нужны самые тонкие механизмы управления ресурсами GPU, которые предоставляют DirectX 12 или Vulkan. Потому что последние, помимо прочего, требуют от разработчиков более глубокой экспертизы и больше ресурсов на разработку всего того же, что на OpenGL и DirectX 11 реализуется меньшими силами и за меньшее время.

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

Информации по каждой отдельной области разработки игр хоть отбавляй. Ее настолько много, что одному человеку за жизнь не усвоить. Поэтому от современного специалиста сегодня требуется спрофилироваться, т.е. определиться со своим профилем работы и стать экспертом.
Я больше 15 лет занимаюсь разработкой игровых движков и медиаферймворков. Более 10 лет занимаюсь коммерческой разработкой кросслпатформенных инструментов. Я начинал свое обучение по книгам и документации для всех интересующих меня областей еще 20 лет назад. Я самостоятельно освоил множество API, включая графические, сетевые, звуковые и API целевых платформ, используя книги и документацию. Экспертные знания C++ и прочих языков я получил тоже через изучение документации, стандартов и книг.
Я могу сказать что обучаться по книгам и документации можно и самостоятельно. Еще можно заплатить деньги и получить более точечные знания через их интерпретацию на распространенных сегодня онлайн-курсах. Такие знания не всегда бывают лучше полученных самостоятельно, но времени на освоение того же объема знаний на курсах уйдет меньше чем при самостоятельном изучении. Иными словами, занятия на онлайн-курсах не отменяют важности самостоятельного изучения основных источников информации.
По открытым видеоурокам на ютубе и прочих видеохостингах обучаться нечему. Цель этих видео - чтобы зритель посмотрел рекламу и этим принес доход автору.

если передать byte[], то сравнивать не хочет, объясните, пожаулйста

Потому что компилятор генерирует вот такое:

EqualityComparer<byte[]>.Default.Equals(<x>k__BackingField, other.<x>k__BackingField);

Если тебе нужно сравнение по содержимому массивов - тебе придётся самостоятельно определить метод с вот такой сигнатурой:

public virtual bool Equals(TypeEncoding other) {
  // код сравнения this с other
}

А также тебе придётся переопределить GetHashCode, чтобы он на одинаковых массивах отдавал одинаковое число.

Но тут есть нюанс - GetHashCode не должен зависеть от изменяемых типов/полей. Тоесть тебе по хорошему нельзя будет менять содержимое этих массивов, а то можешь получить неприятные спецэффекты, если hashcode поменяется.

NULL - это не пустое поле. Это "поле не заполнено".
Используется в тех случаях, когда разница между этими состояниями - есть.
Кроме того, у числовых полей или дат просто нет "пустого" варианта.
0 и '1970-01-01 0:00:00' - это значения, которые вполне могут иметь смысл.
Например, при подсчете средних значений или интервалов NULL позволяет исключить ненужные строки.

Если вам без разницы, заполнил юзер свои поля или нет - значение по умолчанию подходит, использовать NULL просто незачем.

Объекты разные по содержанию, но нам нужны только пару ключей, которые есть у каждого объекта

Почему бы тогда не сделать интерфейс, у которого будут как раз эти пара нужных ключей, которые есть у всех?
Не обязательно же максимально точный и полный тип делать.

type Item = { a: number };
const data: Array<Item> = [ // О том что существует "b" и "c" мы молча забудем :)
  {"a": 1, "b": 42},
  {"a": 2, "c": 33}
];

console.log(data[0].a)

Видимо Хром и потратил место, на кэш, временные файлы и т.п.

Они не отказываются. Скорее происходит отказ от "парадигмы" разработки. Языки стали мульти-парадигменные. Посмотрите на С++20 или Scala. Их невозможно положить в коробочку ООП или ФП. В них есть почти полный набор фич и оттуда и отсюда. И с каждым годом число фич растет и граница размывается. Нашим потомкам будет вообще непонятно где идет раздел.

По поводу golang. Это язык ограниченной разработки. Его создавали специально чтобы порог вхождения был низкий. Фактически делали лайтовый С++ которому можно обучить школьника за 14 дней. Но с перформансом выше чем у Питона. Поэтому выражать какие-то сложные конструкции на типах там скорее всего не получится. У golang есть свой манифест. Я забыл как он называется и где он. Вобщем там довольно четко обоснованно почему такие принципы и почему такая идеология.