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

почему первые два возвращают System.Object и как это можно исправить?

Потому-что dynamic под капотом - это на самом деле Object и куча рефлексии.
List<dynamic> - это на самом деле List<object> (можешь загнать в sharplab и убедиться в этом)

Исправить это можешь только отказавшись от dynamic (а лучше вообще забыть о его существовании. Крайне сломанная фича, которая путём говнокода позволяет в некоторых случаях сэкономить строчки)

Например, если нельзя трогать ClientViewModelNew и ClientViewModelOld, то можно попробовать так:

public interface IClientViewModel {
  public string EXa { get; set; }
}

public class ClientViewModelNewWrapper: IClientViewModel {
  private readonly ClientViewModelNew _internal;
  public ClientViewModelNewWrapper(ClientViewModelNew obj) => _internal = obj;
  public string EXa { get => _internal.EXa; set => _internal.EXa = value;}
}

public class ClientViewModelOldWrapper: IClientViewModel {
  private readonly ClientViewModelOld _internal;
  public ClientViewModelNewWrapper(ClientViewModelOld obj) => _internal = obj;
  public string EXa { get => _internal.EXa; set => _internal.EXa = value;}
}

Очевидно-пропустил запятую на указанной строке

Обычно приватные поля пишут с нижним подчёркиванием, с маленькой буквы. (_context)
С большой буквы, обычно, пишут публичные свойства.
Если у вас в команде принято писать с нижним подчёркиванием и с большой буквы, то пишите так, как принято (_Context)

Ну варианта три:
1. Конвенции
2. Атрибуты
3. MapGet / MapPost итд

Это если не считать всякие сторонние роутеры типа F# Giraffe

Атрибуты были и в .net framework.
А от Convention based все уходят, тк:
1. Не позволяет делать нормальный rest-style роутинг. Да и в принципе маршруты с ним получаются не очень красивые, и не очень предсказуемые.
2. Легко может поломаться

private static void MapEndpoint(

Последнее - это частный случай 3го варианта. Ещё он есть в формате отдельной библиотеки - Carter

Можно указывать порядок свойств для сериализации при помощи атрибута JsonPropertyOrder.

Ещё можно попробовать программно через https://learn.microsoft.com/en-us/dotnet/standard/...
(вот примитивный пример, который не учитывает атрибуты)

using System;
using System.Text.Json;
using System.Text.Json.Serialization;
using System.Text.Json.Serialization.Metadata;

var options = new JsonSerializerOptions
{
    TypeInfoResolver = new DefaultJsonTypeInfoResolver
    {
        Modifiers = { AlphabeticalOrderModifier }
    },
    WriteIndented = true
};

var obj = new MyClassA { X = 42, B = new MyClassB { X = 69 } };
var result = JsonSerializer.Serialize(obj, options);
Console.WriteLine(result);

static void AlphabeticalOrderModifier(JsonTypeInfo jsonTypeInfo)
{
    if (jsonTypeInfo.Kind != JsonTypeInfoKind.Object) return;
    var properties = jsonTypeInfo.Type.GetProperties(BindingFlags.Public | BindingFlags.Instance | BindingFlags.GetProperty).OrderBy(x => x.Name);
    jsonTypeInfo.Properties.Clear();
    foreach (var property in properties)
    {
        var propertyInfo = jsonTypeInfo.CreateJsonPropertyInfo(property.PropertyType, property.Name);
        propertyInfo.Get = property.GetValue;
        propertyInfo.Set = property.SetValue;
        jsonTypeInfo.Properties.Add(propertyInfo);

    }
}

class MyClassA
{
    public int X { get; set; }
    public MyClassB B { get; set; }
}

class MyClassB
{
    public int X { get; set; }
}

Выводит такое (как раз всё в алфавитном порядке, не смотря на то, в каком порядке всё написано в классе):

{
  "B": {
    "X": 69
  },
  "X": 42
}

Второй параметр Random.Range - это верхняя граница НЕ включительно.
Так что тебе нужно просто передать туда 3, вместо 2, как сказал K0TlK

MAUI - это масштабное обновления xamarin-а по сути. ИМХО без поддержки Linux его кроссплатформенность мало чего стоит.
WPF - это нативная технология при этом с WPF тебе доступны всякие сторонние и родные контролы. В том числе самые новые от WinUI 3.
UWP превратился в WinUI 3
Avalonia - кроссплатформа. "Как WPF но лучше", но без поддержки контролов от WPF или WinUI, но есть много свободных вполне неплохих. Да и система стилей достаточно удобная

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

На втором месте наверное AvaloniaUI смущает что на нем каких то больших проектов.

Есть много разных проектов, в том числе крупных и коммерческих, и от именитых компаний.
https://avaloniaui.net/Showcase

Так как программа небольшая я склоняюсь все быстро сделать на Windows Forms, в 2022 году кто то стартует на нем новые проекты?

Если ты делаешь что-то небольшое и чисто для себя, и ты не умеешь работать с XAML и нет времени на освоение - нет причин не использовать Winforms. Да, он имеет проблемы с производительностью, да он не очень красивый, да винформы не очень легко поддерживать. Но является ли это реальной проблемой для вашего проекта?

В общем вот мой топ-чарт:
1. Если дёшево и сердито - Winforms (остальное - если нужен нормальный дизайн)
2. Если кроссплатформу - Avalonia
3. Если нужно на телефоны - MAUI (хотя Avalonia уже можно заставить работать на Android)
4. Если хочется в новый дизайн винды - WinUI 3

Потому что у тебя первая колонка не строка.
reader.GetInt64(0)
или
reader.GetFieldValue<long>(0)

Постгрес не возвращает количество задетых строк в инсерте, как это делают некоторые другие СУБД.

Вот что предлагают на stackoverflow:
https://stackoverflow.com/questions/4038616/get-co... - это вариант, если ты хочешь использовать ExecuteScalar

Npgsql предлагает использовать метод ExecuteNonQuery, который возвращает количество задетых строк:
https://www.npgsql.org/doc/api/Npgsql.NpgsqlComman...

Если ты хочешь получить не количество задетых строк, а саму вставленную строку, то можно попробовать так:
https://stackoverflow.com/questions/2944297/postgr...

В первую очередь они используются во всяких ORM, типа Entity Framework, чтобы лямбды, написанные на C# преобразовывать в SQL.

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

В третью очередь - чтобы сериализовывать названия классов и методов, например в Hangfire.

Это зависит не от студии, а от версии SDK.
В vs2017 используется старый SDK, у которого дефолтная версия была 7.1
VS2022 использует сейчас .NET 7 SDK, у которого дефолтная версия - 11

1. На MacOS нет винформ. Так что никак
2. Если используешь .NET Core или .NET 5 / 6 / 7, то в csproj должно быть что-то наподобие

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net6.0-windows</TargetFramework>
    <Nullable>enable</Nullable>
    <UseWindowsForms>true</UseWindowsForms>
    <ImplicitUsings>enable</ImplicitUsings>

    <ApplicationVisualStyles>true</ApplicationVisualStyles>
    <ApplicationUseCompatibleTextRendering>false</ApplicationUseCompatibleTextRendering>
    <ApplicationHighDpiMode>SystemAware</ApplicationHighDpiMode>
    <ApplicationDefaultFont>Microsoft Sans Serif, 8.25pt</ApplicationDefaultFont>

  </PropertyGroup>

</Project>

TargetFramework и UseWindowsForms - это главное

Есть вроде как способ с массивами, но в массив нельзя добавить ещё массив.

можно.

Если объект сделать, то его нельзя взять по id

Можно запихнуть в Dictionary, где ключом будет id, а значением - объект

List юзать, или что..

Ну в случае листа придётся каждый раз циклом его обходить, чтобы найти предмет.
Проще взять dictionary

1. Не всегда можно указать родительский класс
2. Иногда переход к родительскому классу/интерфейсу не оптимален. Например если ты используешь структуры - будет происходить боксинг.
3. В некоторых случаях потребителю бы хотелось работать с конкретным типом, а не с базовым. Попробуй реализовать List без женериков.

PS: нет такого понятия, как "универсальный класс"

Start, как и Update выполняется в пределах одного кадра.
Делай эту проверку, которую ты делаешь сейчас, внутри Update.
Без while

//нет бесконечного цикла, почему так?

Есть же.
Если условие выхода никогда не будет достигнуто - значит цикл вечный

Смысл имеет, например, для облегчения написания тестов.

Но если эта единственная реализация не мешает писать тесты, то можно и не заморачиваться с намазыванием абстракций.

Например нет никакого смысла вводить интерфейсы для DTO-шек.

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

Вообще тут напрашивается перегрузка для каждого T:

public void SetStrategy(Action<SomeOne> action) {
  _someOne = action;
}

public void SetStrategy(Action<SomeTwo> action) {
  _someTwo = action;
}

Но можно и так, если прям необходимо один метод (стоит задуматься, а действительно ли необходимо):

switch(executor) {
  case Action<SomeOne> one:
    _someOne = one;
    break;
  case Action<SomeTwo> two:
    _someTwo = b;
    break;
  default:
    throw new NotSupportedException($"{typeof(T).FullName} is not supprted");
}