Василий Банников

Нашел решение. Причина - режим Docker fast mode.

В этом режиме сборка образа не запускается и все ограничивается только base этапом. Исполняемое приложение просто маунтится в working_dir. Сам working_dir можно переопределить в свойствах .csproj - DockerFastModeProjectMountDirectory

Отключить этот режим можно в конфигурации запуска - в Modify options указать Don't use Docker fast mode

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

Используй HashSet. Если при Add вернет true - значит есть дубликат

Арифметика-то простая.

DC30-60V

Очевидно, что максимальной мощности мотор достигает при подаче максимального напряжения 60V. При этом потребляемый ток (в амперах) будет = 1350 W / 60 V.
Чтобы не терять энергию на DC-DC преобразователе, лучше сразу подобрать батарею на подходящее напряжение 60V. Грубо считаем, полтора часа на 50% мощности это 0.75 часа на 100% мощности. Значит нужна ёмкость батареи 0.75 h * 1350 W / 60 V ~= 17 A*h
Это при КПД 100% у батареи и КПД 100% у контроллера, а в реальности значит нужна несколько бОльшая ёмкость.
Просто оценка снизу - это 60 V, 17 A*h.

Надо учитывать, что разряд полной ёмкости литиевой батареи за 1.5 часа - это приемлемая, но всё же довольно тяжёлая нагрузка (именно для любой литиевой технологии), будет вызывать заметный нагрев батареи и желательно это как-то контролировать. При сильном перегреве возможно возгорание батареи, в очень редких случаях взрыв.
Допустим, что решили пойти безопасным путём и взяли свинцовую батарею (которой пофигу высокий ток разрядки, в отличие от литиевой), прикидываем её вес на основании имеющихся свинцовых батарей других ёмкостей и напряжений, получаем 25-30 кг для 60 V, 17 A*h. Думаю, неприемлемо. Прикидываем для обычных литиевых АКБ формата 18650, их потребуется около 100 штук (это если брать самые лучшие, ~3400 mA*h, а если брать подешевле меньшей ёмкости, то их количество ещё нужно увеличивать) и весить они будут (без учёта какой-то конструкции, в которой они будут держаться) около 5 кг. Уже вполне терпимо, но ещё раз скажу: контролируйте нагрев таких батарей, как при заряде, так и при разряде!
Если где-то найдёте подходящую тяговую батарею (т.е. изначально рассчитаную для питания электромотора на каком-то транспорте), то это, вероятно, будет оптимально. Попробуйте поискать батареи для электровелосипедов, для электросамокатов; я не знаю, какие там характеристики, но вполне возможно, что подберёте что-то подходящее.

Смотрел готовые варианты - отлично, но большинство в моем бюджете либо маломощные, либо с маленькой батареей

Бюджет не озвучен, так что прикидывайте самостоятельно. По-моему 100 штук самых крутых (по ёмкости) батареек 18650 будут стоить не так уж мало.

Обычно слово On, потом участник и событие, типа OnBackButtonClick, без таких __

Никак. Выбор инструмента - это задача тимлида и/или техлида. Т.е. ведущего/главного разработчика, отвечающего за принятие ключевых технических решений. Ваша задача, как заказчика, четко оформить требования, ограничения и сформировать начальное ТЗ и описание, что вам требуется от проекта, прототипы интерфейса, например. Без вникания в технические детали. Т.е., "хочу чтобы были фичи такие-то и работил они так-то, ограничения такие-то, требования такие-то". Далее уже задача найти разработчика/команду с большим или достаточным для данного проекта опытом. Далее из начального ТЗ формируется полноценное техническое задание: описывается весь требуемый функционал, рисуется дизайн, прописываются требования, ограничения и прочие хотелки. И на основе ТЗ, тим/тех лид уже подбирает/подбирают наиболее оптимальные и конкретные инструменты и решения, основываясь на собственном опыте и знаниях для конкретно этой задачи. Например, если человек хорошо знает несколько разных инструментов и есть достаточный опыт их использования - он может реализовать проект используя любой из них как одинаково хорошо, так и одинаково плохо. У разных ЯП и фреймворков свои плюсы и минусы. Далее из ТЗ формируется более детальное ЧТЗ и происходит разработка проекта.

Вот вы говорите:

Нужно будет выполнять много запросов к БД

Важная быстрая скорость работы нашего сайта

Много/быстро это сколько? 100 запросов в час? 1000 в минуту? 1М в секунду? Загрузка страницы за 30/10/1с или даже 100мс? А к какой именно БД? Какая характеристика самих данных и какого типа запросы? На какое количество соединений? В каком регионе? Есть ли там тяжелые или еще какие-то вычисления? Медиа файлы - картинки, видео? Тут очень много нюансов. В идеале следует определиться с конкретными значениями/параметрами и их описать в ТЗ. Ну или определить примерное, а фактическое значение определить на стадии прототипа/MVP и/или провести какое-то исследование/тестирование. Можно потратить десяток лямов на написание крутого кода на го/расте/С++/ассемблере в течении года и все будет летать на простейшем сервере. А можно купить свой сервер за лям (ну, условно, конечно), нанять питонщика или PHP-ника за 300к и он за пару-тройку недель добьется такого же результата. Большинство веб-задач сегодня достаточно просто или с минимальными усилиями решаются абсолютным большинством решений для веба. Да, у всех решений есть свои плюсы и минусы.

Безопасность от всяческих XSS и SQL атак.

Вот с этим проще: использовать популярные OpenSource решения, регулярно проводить тесты, нанять отдельно опытного разработчика, красноглазика и пентестера - и тратить на них деньги, пока деньги не кончатся или не будет достигнут необходимый уровень безопасности. Безопасность противоположна удобству, защита отстает на шаг от атак. Риск есть всегда и надо просто быть готовым к последствиям и иметь запасной плат хотя бы в общих чертах.

А так - уже правильно посоветовали сразу брать дот-нет, т.к. у вас требование к использованию конкретной библиотеки для дот-нета.

Ну раз с фронта пересели, то аналогию понять должны: В чëм отличие Google Chrome от JavaScript?

Там выше посоветовали книгу Конрада Кокосы, добавлю от себя книгу Саши Гольдштейна и у Станислава Сидристого есть недописанная книга. Еще на ютубе с dotNext`а можно посмотреть, что то было интересного про внутненности dotnet`а.

Управление памятью в .NET для профессионалов

Как работает сборка мусора.
В .NET используется 2 фазная сборка мусора: Mark & Sweep (Пометить и Убрать).

Mark

На этом этапе обходится весь граф объектов. И выявляются все недостижимые.

Каким образом достижимость объектов определяется?

Достижимые это:
- Аллоцированные на стеке
- В статических полях
- Достижимые из достижимых (см. выше)

Все объекты, которые не удалось достичь (в граф не попали) - являются недостижимыми.

Но на стеке лежат числа. могут быть как числами, так и адресами, как и числами?

JIT копилятор достаточно умный, чтобы сгенерить код, который будет знать, что за объект/ссылка лежит на стеке. Так и получаются знания об объектах.

Sweep

Тогда итог, что языки с сборщиком мусора, под в 2 раза медленнее должны быть.(помимо сборки)

Вот тут интереснее. Есть несколько хаков как достигается большая производительность.
1. Линеризованное пространство памяти.
Адреса 0, 1 и 2 поколения расположены не абы где, а последовательно, друг за другом. Т.е. если нужно сократить пространство 0 поколения, то это означает простое передвигание указателя влево.

2. Переход в след. поколение происходит не всегда
Из 0 в 1 - переход быстрый, но из 1 в 2 - не всегда.
На этом этапе тоже может не затрачиваться много времени.

3. Ссылки из недостижимых объектов не обновляются - эти объекты и так нигде не участвуют
Обновление ссылок, к сожалению, - это ручное изменение и копирование. Ничего не поделаешь.

Теперь где-то, сборщик мусора, начинает переносить arr в другое место.

Ты слишком большой массив выделил, он аллоцируется в LOH. Оттуда не вытащишь.

Я много о чем не упомянул. Например, очередь финализации, таблица дескрипторов (Handle), сегментирование памяти и т.д. но ответы на основные вопросы дал

Так задумано. Неактивные вкладки имеют низкий приоритет, поэтому там не гарантируется исполнение в риалтайме js.
Выход переписать например на webworker.
В целом тема обширная, можешь гуглить JavaScript inactive tabs

Во-первых, у let блочная область видимости:

>> let a = 0;
<- undefined
>> window.a
<- undefined

Во-вторых:

function foo(x) {
  this.x++
}

Вот в этой функции, локальная переменная x и свойство x объекта this - это разные вещи.

Если хочется иметь функцию, которая будет менять определенное или произвольное свойство объекта window или произвольного объекта - то делать надо это явно и прямо. Например:

window.x = 0
window.x++

Или же:

let propName = 'a'
window[propName] = 0
window[propName]++