Сергей Соловьев

На SO уже есть похожий вопрос.

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

Код оттуда

class MyItemConverter : JsonConverter
{
    public override bool CanConvert(Type objectType)
    {
        return typeof(ItemToSell).IsAssignableFrom(objectType);
    }

    public override object ReadJson(JsonReader reader, Type objectType, object existingValue, JsonSerializer serializer)
    {
        JObject obj = JObject.Load(reader);
        string discriminator = (string)obj["ObjectType"];

        ItemToSell item;
        switch (discriminator)
        {
            case "apple":
                item = new Apple();
                break;
            case "books":
                item = new Books();
                break;
            case "melon":
                item = new Melon();
                break;
            default:
                throw new NotImplementedException();
        }

        serializer.Populate(obj.CreateReader(), item);

        return item;

    }


    public override void WriteJson(JsonWriter writer, object value, JsonSerializer serializer)
    {

    }
}

dotnet new --list

На чем основывалась проверка? Какой инструмент?

Во-первых, У .NET есть двухуровневая система генерации кода. Это Tiered JIT.

0 уровень ничего не оптимизирует. Это для оптимизации старта.
1 уровень уже запускает оптимизации и генерирует оптимальный код. Чтобы запустить его запусить, надо очень много прогнать код.

P.S. именно поэтому BenchmarkDotNet делает очень много WarmUp, Preworkload и других стадий перед запуском реальных бенчмарков.

Во-вторых, в какой конфигурации запускали: Debug или Release?

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

Microsoft создал референсный микросервисный проект - eShopOnContainers. Там есть основные паттерны проектирования, клиенты различные (ajax, mvc).

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

Если есть время, то можно и книгу прочитать по этой архитектуре

Надо указывать схему авторизации.
В атрибут Authorize добавить надо строчку схемы авторизации.

[Authorize(JwtBearerDefaults.AuthenticationScheme)]

builder.Services.AddScoped<IService, ServiceImplementation>();

в Program.cs

Потом через конструктор контроллера получаешь интерфейс.

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

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

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

Mark

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

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

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

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

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

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

Sweep

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

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

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

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

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

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

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

Сделай как Task: вместо интерфейсов - конкретные классы.

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

В C# нет перегрузки по возвращаемому значению. В случае наследования интерфейсов (первый пример) ты создаешь метод и идентичной сигнатурой, но при этом различными возвращаемыми значениями. Вот он и ругается.

Дополняя ответ Василий Банников.

- Vector3 - это вектор из 3 координат
- Quaternion - это вектор из 4 координат

Невозможно преобразовать, т.к. откуда знать что за 4-ая координата

В Rider это можно сделать через тот же самый Add Reference.
Правая кнопка по проекту -> Add -> Reference... -> Внизу нажимаешь "Add from..." -> Находишь свой dll