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

https://learn.microsoft.com/ru-ru/dotnet/csharp/la...
Предположу, что ругается на эти строчки, которые действительно не имеют смысла:

public void InitializePlayer()
{
string = Player;
}

public void AddScore(int points)
{
int = 0;
}

Как исправить - знает только автор.
Чтобы в будущем до такого не доводить - пиши в нормальном редакторе, который сразу подсвечивает проблемы, а не в блокноте.

.NET Framework - это старая платформа, которая изначально в 2000х появилась.
Потом в 2016 или типа того году появился .NET Core и .NET standart.

.NET Core - новая, кроссплатформенная платформа, в которую изначально завозили всякие новые штуки типа нового JIT, вносили новые API, убирали старые, завозили новые фичи C#.

.NET standart - спецификация, которая позволяет делать библиотеки, которые работают и на .net framework и на .net core с гарантией совместимости.

Часть нововведений .NET Core вернулась в .NET Framework, а часть - нет.

Потом произошёл ребрендинг и .NET Core переименовали в просто .NET, а .netstandard прекратили обновлять, тк все новые api теперь идут только в .NET, но не в .NET Framework.

Как я понял .Net и .Net framework это программы, которые преобразуют папку с проектом в исполняемый файл, другими словами говоря - компиляторы.

Не совсем. Есть две вещи:
1. .NET runtime и .NET SDK
2. .NET Framework и .NET Framework DevPack
То что слева - это только рантайм, он отвечает за запуск уже собранных приложений.
А вот в sdk уже входит компилятор и все необходимые для сборки приложений библиотеки.

Сами по себе они отличаются тем, что .Net framework создаёт файл, запускающейся только на винде, а .Net - и на маке и на линуксе.

Различие между .NET Framework и .NET я уже описал выше, но повторю:
1. .NET Framework - старый/устаревший, менее производительный, и только windows (mono упоминать не будем)
2. .NET с номером - новый/современный, более производительный, работает на разных платформах.

Для нового проекта стоит выбирать только номерной .NET (сейчас вроде 9), если у тебя нет весомых доводов для выбора .NET Framework.

1. Да, это нормально. Сильно легче код писать таким образом. (а иногда и читать, тк меньше слов дублируется. Например совершенно никакой ценности не несёт User user = userRepository.GetUserById(...) или многослойный женерик)

2.

Я ужасно ненавижу такой подход, потому что ты не можешь сразу определить тип, который возвращается.

А ты давай нормальные названия методам, чтобы возвращаемое значение было очевидным, набирайся опыта, ищи закономерности.

Ты же не задаёшься вопросом, какой тип возвращает какой-нибудь GetUser, ToString, TryParse, FirstOrDefault?

Если тебе сложно понять смысл кода без типов - значит кто-то плохие имена дал переменным.

Данный код достаточно сложно разобрать человеку, который не писал это всё с нуля, а был присоединён через 4-5 лет ведения проекта.

Очень смелое заявление, которое мало чем подкреплено.

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

1. var далеко не только для анонимных типов полезен, хотя с анонимными типами без var работать было бы очень сложно.

2. Тренд говорит об обратном - автоматический вывод типов сейчас есть практически во всех статически-типизированных языках в том или ином виде.

Ну и помни ещё, что ты же не в блокноте код пишешь - у тебя есть всякие inlay hints, которые могут рядом с именем переменной показать её тип, а наведя мышку на слово - ты узнаёшь о нём все (имя переменной, сигнатуру метода, документацию, итд)

Посмотри в сторону Microsoft.CodeAnalysis.CSharp.Scripting, но экзешник с помощью неё ты не сделаешь вроде бы

https://weblog.west-wind.com/posts/2022/Jun/07/Run...

var str = "a b c";
var list = str.Split(' ').ToList();

А вот почему юнити зависает - надо смотреть на код целиком.
То что написано в вопросе не является валидным C#-кодом в принципе.

Раз для C#, то посмотри в сторону Rider или VS Code.
Ну или подумай над вариантом перейти на win 10 / 11
Ну или торренты

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

Вот пример из комментариев о том, как делать не стоит:

class Character {
  public double health;
  public void TakeDamage(double damage) {
    if(damage <= 0) return;
    this.health -= damage;
    if(this.health <= 0) {
       this.Die();
    }
    // ...
  }
  public void Die() {
    this.DoSomethingSpecial();
    // ...
  }
  
  // Этот метод в будущем будет удалён, оставлен пока как костыль
  public void DoSomethingSpecial() {/*...*/}
}

Потом спустя хз сколько времени ты вернулся к коду.
Как ты будешь вспоминать, как правильно стоит наносить урон персонажам?
Через TakeDamage или в каких-то случаях можно напрямую изменить поле health?
Если в каких-то случаях нужно напрямую использовать поле health, то в каких?
Если ошибёшься - возникнут закономерные баги.

Про скрытие деталей реализации:
Допустим, что ты решил добавить в игру поддержку модов.
Как разработчик мода поймёт, какие методы на персонажах можно вызывать не беспокоясь о том, что мод сломается в следующей версии игры?
Например без использования модификатора internal - разработчик мода может подумать, что этот метод можно вызывать, а по факту - в следующей версии ты, как разработчик игры, планируешь его удалить или изменить сигнатуру, что поломает мод.
+ если у тебя многие вещи сделаны через поля, то тогда ты не сможешь использовать интерфейсы (ну или их использование будет затруднено)

то уже нет смысла ни в UnitOfWork, ни в Repository. То есть можно избавиться от Infrastructure слоя, чтобы схема была уже такая: UI, Application, Domain.

Infrastructure слой нужен не для того чтобы заменять базу в будущем, а чтобы работа с базой не захламляла домен.
Да и "никогда переходить не планируется" - это достаточно громкое заявление.

Просто в случае с UnitOfWork и Repository накладывают только лишнюю нагрузку, потому что это и так реализовано в EntityFramework.

Тогда будет усложнено тестирование, так как ты не сможешь замокать EF.
Лучше всю работу по построению запроса тоже вынести куда-то в инфраструктурный слой - тогда и UoW и "Repository" не придётся тащить в домен.

Кестрел то актуален. Не актуальны сейчас пакеты с 2.2 и ранее.
Сейчас всё что связано с aspnetcore идёт сразу вместе с sdk, а не как раньше (всё ещё выглядит как очень странное решение со стороны мс)

И он используется по-умолчанию и так.
https://learn.microsoft.com/ru-ru/aspnet/core/fund...

Вообще раз уже допускается наличие сетевого соединения между клиентом и сервером, то напрашивается просто вынести все критические функции на сервер.

Но я просто пытаюсь угадать что и от чего ты пытаешься защитить.

Переменные окружения всегда хранятся в переменных окружения.

.env-файл - это не переменные окружения, а конфиг, который потом должна подхватить программа и добавить данные из него в свои переменные окружения.
В .NET есть пакет, который делает ровно это: https://www.nuget.org/packages/dotenv.net

В .net для конфигов принято использовать классы и интерфейсы из Microsoft.Extensions.Configuration.
Самый распространённый вариант конфига - файл appsettings.json.

Если мне память не изменяет, то m.e.c по-умолчанию в asp net core настроен так, чтобы тащить конфиги из appsettings, переменных окружения, и аргументов командной строки.

Отдельно можно ещё сделать интеграцию и с другими вариантами конфигурации при помощи "Configuration providers".

Подробнее можно почитать в документации: https://learn.microsoft.com/en-us/aspnet/core/fund...

1. C++ - это не единственный способ хорошо понять, как работает компьютер. Раз уж это первый язык, то я бы смотрел сразу в сторону Rust, тк он также сразу учит тебя тому, как можно управлять памятью.

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

3. Просто открываешь книгу или курс и читаешь, делаешь всё более и сложные проекты. Всё.
Выбирая литературу - смотри на автора и отзывы.

4. Если хочешь начать карьеру с C++, то тут мастхев будет диплом какого-нибудь хорошего вуза, чтобы тебя рассматривали всерьёз. (тоесть закладывай ещё +3 года после окончания колледжа).
Хотя опять же - начинать карьеру с C++ сейчас - это крайней сомнительный выбор, если не геймдев, конечно.
Для джуна в принципе разницы нет - на любом стеке тебе будет крайне тяжело найти первую работу.
Для опытного аналогично, но наоборот - на любом стеке, если он не совсем мёртвый, найти работу будет вполне реально. (в худшем случае пара месяцев на поиск наиболее вкусного предложения).
Сам в вполне успешно получал оффер на такую экзотику, как F#, а сейчас вообще пишу на Rust.

Ну сборка - это то что в dll-файле, да.

Где ты прочитал о статических и динамических я не знаю, по тому загуглил сам.

Статическая сборка - это такая, сборка, которая сохранена как dll-файл.
Динамическая - которая создана при помощи System.Reflection.Emit и существует только в рантайме.